[libvirt] PATCH: support virtual disks
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> 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. --- diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 64b5cf3..b753734 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -103,7 +103,8 @@ VIR_ENUM_IMPL(virDomainDeviceAddress, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST, VIR_ENUM_IMPL(virDomainDisk, VIR_DOMAIN_DISK_TYPE_LAST, "block", "file", - "dir") + "dir", + "virtual") VIR_ENUM_IMPL(virDomainDiskDevice, VIR_DOMAIN_DISK_DEVICE_LAST, "disk", @@ -1434,6 +1435,9 @@ virDomainDiskDefParseXML(xmlNodePtr node, case VIR_DOMAIN_DISK_TYPE_DIR: source = virXMLPropString(cur, "dir"); break; + case VIR_DOMAIN_DISK_TYPE_VIRTUAL: + source = virXMLPropString(cur, "path"); + break; default: virDomainReportError(VIR_ERR_INTERNAL_ERROR, _("unexpected disk type %s"), diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index f83de83..9bb5073 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -119,6 +119,7 @@ enum virDomainDiskType { VIR_DOMAIN_DISK_TYPE_BLOCK, VIR_DOMAIN_DISK_TYPE_FILE, VIR_DOMAIN_DISK_TYPE_DIR, + VIR_DOMAIN_DISK_TYPE_VIRTUAL, VIR_DOMAIN_DISK_TYPE_LAST }; diff --git a/src/qemu/qemu_security_dac.c b/src/qemu/qemu_security_dac.c index ffc9b8d..69c7bf1 100644 --- a/src/qemu/qemu_security_dac.c +++ b/src/qemu/qemu_security_dac.c @@ -374,7 +374,7 @@ qemuSecurityDACSetSecurityAllLabel(virDomainObjPtr vm, const char *stdin_path AT for (i = 0 ; i < vm->def->ndisks ; i++) { /* XXX fixme - we need to recursively label the entriy tree :-( */ - if (vm->def->disks[i]->type == VIR_DOMAIN_DISK_TYPE_DIR) + if (vm->def->disks[i]->type == VIR_DOMAIN_DISK_TYPE_DIR || vm->def->disks[i]->type == VIR_DOMAIN_DISK_TYPE_VIRTUAL) continue; if (qemuSecurityDACSetSecurityImageLabel(vm, vm->def->disks[i]) < 0) return -1;
On 06/11/2010 03:52 AM, 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>
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.
Hi Andrew, Haven't taken a look at how NBD devices attach to the host system yet, so I'm just trying to understand the concept here. I'm used to some other network storage types (ie SRP LUNs), that when configured on a host system present as a disk device. These can then be configured using various storage pool types (ie disk, dir, fs, etc) as per a "standard" locally attached device. Kind of wondering if NBD should be like that too? Regards and best wishes, Justin Clift -- Salasaga - Open Source eLearning IDE http://www.salasaga.org
On 10 Jun 2010, at 17:22, Justin Clift wrote:
Haven't taken a look at how NBD devices attach to the host system yet, so I'm just trying to understand the concept here.
I'm used to some other network storage types (ie SRP LUNs), that when configured on a host system present as a disk device. These can then be configured using various storage pool types (ie disk, dir, fs, etc) as per a "standard" locally attached device.
Kind of wondering if NBD should be like that too?
NBD devices don't show up on the host as block devices (or, indeed, at all). Instead, the QEMU process communicates directly with the storage node over the network. Whether this is preferable or not is debatable, but a bit of a moot point now, as it's already implemented in QEMU like this. :) More importantly, this opens the way for other potential QEMU block devices which work similarly.
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 :|
On 11 Jun 2010, at 06:28, Daniel P. Berrange wrote:
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.
Unfortunately, this is simply the way qemu presents virtual disks. nbd is one of its block drivers, right along with all of the other format drivers like qcow2. The format of the data stored on nbd is invisible to qemu -- it's probably raw on the remote disk, though.
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>
Specificity is good, but what I'm really trying to accomplish here is generic support for any type of atypical, non-file block device which libvirt isn't natively aware of. I understand the desire to model everything as specifically as possible, but it'd help to also have an "out" for drivers which aren't modeled yet.
participants (3)
-
Andrew Farmer -
Daniel P. Berrange -
Justin Clift