[Users] How to make oVirt I/O write faster than Virtualbox and others?

[Adrian Gibanel]

----- Mensaje original ----- 

> De: "Yaniv Kaul" <ykaul at redhat.com>
> Para: "Adrian Gibanel" <adrian.gibanel at btactic.com>
> CC: "users" <users at 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 .