Re: [libvirt] PATCH: support virtual disks
On Thu, Jun 10, 2010 at 10:52:28AM -0700, Andrew Farmer wrote:
Libvirt currently makes the assumption that disk devices are always
accessible as files on the local system. However, certain types of virtual storage on qemu
(e.g, NBD) may not be. This patch defines a new "virtual" disk device which is
treated similarly to existing disk types, but which is exempted from at least one code
path (qemuSecurityDACSetSecurityAllLabel) which assumes the disk to be accessible as a
file.
With this patch in place, a QEMU virtual disk can be declared as:
<disk type='virtual' device='disk'>
<driver name='qemu' type='nbd' />
<source path='nbd:nbdhost:1234' />
<target dev='vda' bus='virtio' />
</disk>
This isn't really very good as a data format, because it is treating
the 'path' attribute as an opaque blob into which any old junk can be
stuffed & passed straight on down to QEMU. You've bypassed the issue
of the security driver trying to treat it as a file, but made it
impossible for the security driver todo anything else with it. The XML
formats should have one attribute per piece of information, rather
than stuffing the compound string into one single attribute. Setting
the driver type='nbd' is not correct either - the type attribute refers
to the format of the disk, not the access mechanism. By using 'type=nbd'
it is now not possible to indicate that this ndb device actually points
to qcow2 formatted data. If we want to support NBD as a disk backend
protocol, then I think we need something more along the lines of
<disk type='nbd' device='disk'>
<driver name='qemu' type='qcow2' />
<source host='the-nbd-server' port='1234' />
<target dev='vda' bus='virtio' />
</disk>
I haven't tested this with any drivers besides QEMU, so there
might be
some adjustments needed for those as well. Having the infrastructure in
place to create these devices makes it easier to add them in the future,
though.
Easy != good I'm afraid. Further access protocols need to be explicitly
modelled in the XML too, rather than just using a generic 'virtual' catch
all case.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|