12:52 p.m.
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;
7:22 p.m.
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
7:48 p.m.
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.
8:28 a.m.
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 :|
2:22 p.m.
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.
5308
days inactive
5309
days old
4 comments
3 participants
participants (3)
-
Andrew Farmer -
Daniel P. Berrange -
Justin Clift