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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list