[libvirt] PATCH: support virtual disks

[Andrew Farmer]

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.