When defining a guest's block device in the libvirt XML we currently allow
the dev to be backed by either a file or block device in the host system.
This is done by specifying the 'type' attribute when defing the block
device XML.
eg
<disk type='file'>
Or
<disk type='block'>
This is all fine & dandy for Xen 3.0.2, but in 3.0.3 we now have a choice
of drivers for the 'file' backed block devices. We can either use the
traditional loopback mounted system, or the new blktap system. To complicate
things further still, blktap itself has man different drivers - one uses
a raw file with Async-IO, another uses the QCow sparse format with AIO,
and all sort of other possibilities are available...
This means the easy option of just making all file devices use blktap in
3.0.3 is not practical. This in turns means we need to come up with a
way to express the new driver methods in libvirt XML. There are a few
options I can think of :
- Allow more values in the 'type' attribute, eg file, block, blktap:aio,
blktap:qcow, etc. This feels wrong because the blktap:* entries are
really still 'file' types.
- Introduce a new attribute 'driver' where you can specify 'loop',
'blktap:aio', 'blktap:qcow', etc
- Introduce a new element 'driver' where you can specify the same
<disk type="file">
<driver type='blktap:aio'/>
</disk>
- Same as above, but normalize the driver type further
<disk type="file">
<driver type='blktap' backend='aio' />
</disk>
My preference is probably option 3 or 4.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|