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@xxxxxxxxxxxxxxxxx> > > >>> > > >>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list