11:53 a.m.
----- Mensaje original -----
De: "Yaniv Kaul" <ykaul(a)redhat.com>
Para: "Adrian Gibanel" <adrian.gibanel(a)btactic.com>
CC: "users" <users(a)ovirt.org>
Enviados: Jueves, 7 de Marzo 2013 8:08:55
Asunto: Re: [Users] How to make oVirt I/O write faster than
Virtualbox and others?
----- Original Message -----
>
> Every benchmark out there features KVM as the best virtualisation
> technology. Even in the I/O write category. My results with oVirt
> are deceiving. So I'm going to explain my test machine, setup and
> ask your for advice to find out what's wrong. Any more data you
> need please ask for it. I like oVirt mostly because of its
> datacentre-aware web manager. But if it gets unusable I would have
> to take a look at other systems.
> Some random questions:
>
> * Is it a problem that sandbridge architecture is being detected as
> an Intel Conroe architecture?
> * Is there any easy way to test aio=native in oVirt when running
> virtual machines just for testing it?
Our testing showed that aio=threads works better for file-based
storage (vs. aio=native for block storage).
> * Should I test oVirt 3.2? Is there any improvement in I/O
writing?
Probably not, but you should try with oVirt 3.2 nevertheless, for
the
wealth of other features that might be useful now or later (direct
LUN for example).
Interesting.
> * What about Fedora 18? Any improvements in I/O writing or, I
don't
> know, the Virtio system?
Probably a newer QEMU and KVM can provide better performance. Did
not
go through the complete changelog to verify it.
Ok.
> * Any ovirt-node package for Debian/Ubuntu? The wiki seems like
a
> draft (http://www.ovirt.org/Ovirt_build_on_debian/ubuntu).
> * Any I/O write consuming package that I should remove from stock
> Fedora just before installing it from the web manager?
>
> So... Any idea?
I'd start with comparing the complete QEMU command line between
the
instances. I don't think it's only the -cpu that'll affect the
performance (unless the test is CPU bound?). Specifically, what
about the cache= setting? We use, for data safety, cache=none.
That's what I did in the proxmox's manually run qemus.
Some news:
---------------------
Although I haven't done a proper check I think it has improved a lot by disabling cpu
scaling and letting performance
Take a look at:
http://forums.fedoraforum.org/showthread.php?t=272109
Proxmox with direct LV as a hard disk is still faster but that makes sense because oVirt
3.1 only worked with files in filesystem and not with LVs. Maybe that 3.2 direct LUN
support implies also LV support.
--
--
Adrián Gibanel
I.T. Manager
+34 675 683 301
www.btactic.com
Ens podeu seguir a/Nos podeis seguir en:
i
Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de
tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es
cosa de todos.
AVIS:
El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el
destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense
tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem
que ho feu saber immediatament al remitent i que procediu a destruir el missatge .
AVISO:
El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario,
les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la
autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos
que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .