[libvirt] RFC: using a network device as a destination for a disk snapshot

[Daniel P. Berrange]

On Wed, Oct 30, 2013 at 08:44:32AM -0600, Eric Blake wrote:
> Right now, when creating an external snapshot, the snapshot xml requires
> that the destination be in the local file system:
> 
> http://libvirt.org/formatsnapshot.html
> 
> <domainsnapshot>
>   ...
>   <disks>
>     <disk name='vda' snapshot='external'>
>       <driver type='qcow2'/>
>       <source file='/path/to/new'/>
>     </disk>
> ...

Interesting - we're missing the 'type' attribute here to distinguish
file vs block too - which impacts on the attribute name in the
<source> element - eg <source dev="/dev/foo1"/>

> But libvirt already allows for a network device with qcow2 contents,
> provided that there is no backing chain:
> 
> # qemu-img info gluster://red/vol1/img2
> image: gluster://red/vol1/img2
> file format: qcow2
> virtual size: 10M (10485760 bytes)
> disk size: 193K
> cluster_size: 65536
> # virsh dumpxml dom
> <domain type='kvm'>
>   ...
>     <disk type='network' device='disk'>
>       <driver name='qemu' type='qcow2'/>
>       <source protocol='gluster' name='vol1/img2'>
>         <host name='red'/>
>       </source>
>       <target dev='vdc' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
> function='0x0'/>
>     </disk>
> ...
> 
> I'm working on patches to the backing chain code to allow a gluster (or
> other network device) with qcow2 contents to have a backing file, but
> for the code to be useful, we also need to patch <domainsnapshot> xml to
> allow the destination file to be a gluster or other network device,
> rather than forcing it to be a local file name.
> 
> Here's the XML I think we need to add to domainsnapshot:
> 
> <domainsnapshot>
>   ...
>   <disks>
>     <disk name='vda' snapshot='external' type='network'>
>       <driver type='qcow2'/>
>       <source protocol='gluster' name='vol1/img2'>
>         <host name='red'/>
>       </source>
>     </disk>
> 
> that is, add an optional /disk at type attribute (if absent, it defaults to
> type='file'), and where if present, the <source> subelement then takes
> on alternate forms in the same manner in which //domain/devices/disk
> handles alternates (here, allowing a protocol, name, and host
> specification).

We should wire up type=block while fixing this, so we have consistent
representations. Indeed, is there a way to share the parsing code for
this between the two schemas, to guarantee consistency ? Likely just
want to share the source specification part of the schema (eg the QEMU
"backend" config equivalent).

> [Ultimately, we need to fix //domain/devices/disk to specify a full
> backing chain, but one step at a time...]

Yep, we'd want to fix the <domain> <disk> schema to deal with this
before we consider what it means for <domainsnapshot> (if anything)

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|