[Libvir] Supporting new Xen 3.0.3 blktap backend for file devices

Daniel P. Berrange berrange at redhat.com
Tue Sep 26 19:08:33 UTC 2006


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  -=| 




More information about the libvir-list mailing list