[libvirt] [PATCH] Support for qemu aio drive option

[Daniel P. Berrange]

On Tue, Jan 04, 2011 at 08:12:21AM -0500, Chris Lalancette wrote:
> On 01/03/11 - 04:43:06PM, Eric Blake wrote:
> > On 05/17/2010 03:31 PM, Eric Blake wrote:
> > > [adding Matthias on cc]
> > 
> > Reviving an old thread, as it is something I plan on working in the near
> > future.
> > 
> > > 
> > > On 05/17/2010 03:07 PM, Chris Lalancette wrote:
> > >> On 05/12/2010 11:26 PM, Eric Blake wrote:
> > >>> From: Matthias Dahl <mdvirt at designassembly.de>
> > >>>
> > >>> qemu allows the user to choose what io storage api should be used, either the
> > >>> default (threads) or native (linux aio) which in the latter case can result in
> > >>> better performance.
> > >>>
> > >>
> > >> The implementation looks perfectly reasonable.  I'm just concerned that the
> > >> concept of what we are doing is too qemu specific, though.  Basically, I think
> > >> what we are trying to model here is the concept of an I/O backend implementation,
> > >> correct?  Should we maybe change this to be "<iobackend type='%s'/>", and then
> > >> have available enums like:
> > >>
> > >> aiothreads
> > >> aionative
> > >> ...
> > >>
> > >> That way, for other hypervisors that do something different (like VirtualBox,
> > >> which just has AIO on/off), we can have additional enums to describe their
> > >> behavior.  Even further, if a given hypervisor wanted to do something like
> > >> "Direct I/O" for the I/O backend (as an example), we could also use this element
> > >> to specify that.  What do you think?
> > > 
> > > Indeed, having a more-generic attribute "type", where only a subset of
> > > known enum values are appropriate per a given hypervisor, makes sense to
> > > me.
> > 
> > I'm thinking that the following XML changes make the most sense for this
> > (note that the choice of aio mode is per-disk), where the change is the
> > addition of the new <iobackend> element:
> > 
> > <domain ...>
> >   <devices>
> >     <disk type='block' device='disk'>
> >       <driver name='qemu' type='qcow2' cache='none'/>
> >       <source dev='...'/>
> >       <target dev='hda' bus='ide'/>
> >       <iobackend type='aiothreads'/>
> >     </disk>
> >   </devices>
> > </domain>
> > 
> > If <iobackend> is missing, it is the same as type='default'; type can be
> > 'default' (whatever qemu prefers, which may differ over qemu versions),
> > 'aiothreads' (use ,aio=threads in qemu -drive argument), or 'aionative'
> > (use ,aio=native in qemu -drive argument); where we can add other types
> > later if needed.
> > 
> > Does this deserve a new <iobackend> element, or should it merely be a
> > new optional attribute of the existing <driver> element, as in:
> > 
> > <driver name='qemu' type='qcow2' cache='none' iobackend='aiothreads'/>
> 
> I slightly prefer making it a new attribute of <driver>.  The only reason I
> can see to make it a new <iobackend> element is if we think it will get
> significantly more complex in the future (necessitating new XML elements).  Do
> we think that?

Yep, the whole '<driver>' element is really specifying an I/O backend,
so I don't think it makes sense to add another <iobackend> element,
nor is it particularly great as an attribute name. It should be an
attribute on <driver> though

Daniel