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(a)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'/>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org