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@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 :|