On Wed, Mar 12, 2014 at 02:21:46PM -0600, Eric Blake wrote: > # virsh vol-dumpxml --pool gluster img3 > <volume type='network'> > <name>img3</name> > <key>vol1/img3</key> > ... > <target> > <path>gluster://localhost/vol1/img3</path> A shame we chose this representation instead of something that matched the format used in the domain XML. At least we can add the domain XML format here without breaking compat. > Proposal > ======== > For each <disk> of a domain, I will be adding a new <backingStore> > element. The element is optional on input, which allows libvirt to > continue to understand input from older versions, but will always be > present on output, to show what libvirt is tracking as the backing chain. > > For a file with no backing store (including raw file format), the usage > is simple: > > <disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='/path/to/somewhere'/> > <backingStore/> > <target dev='vda' bus='virtio'/> > </disk> > > The new explicit <backingStore/> makes it clear that there is no backing > chain. > > A backing chain of 3 files (base <- mid <- top) in the local file system: > > <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source file='/var/lib/libvirt/images/top.qcow2'/> > <backingStore type='file'> > <driver name='qemu' type='qcow2'/> > <source file='/var/lib/libvirt/images/mid.qcow2'/> > <backingStore type='file'> > <driver name='qemu' type='qcow2'/> > <source file='/var/lib/libvirt/images/base.qcow2'/> > <backingStore/> > </backingStore> > </backingStore> > <target dev='vda' bus='virtio'/> > </disk> > > Note that this is intentionally nested, so that for file formats that > support more than one backing resource, it can list parallel > <backingStore> as siblings to describe those related resources (thus > leaving the door open to expose a qemu quorum as a <disk type='quorum'> > with no direct <source> but instead with three <backingStore> sibling > elements for each member of the quorum, and where each member of the > quorum can further have its own backing chain). I understand why you chose to use nesting, but I can't say I like the appearance of nesting. I think that in the common case where we have a single non-branching chain, the XML structure is kind of unpleasant and would be nicer if just a flat list. Using nesting makes it harder to extract info about backing files from the XML structure with XPath because you can't simply ask for all <source> elements at a given location. If we're going to add <alias> I wonder if we should just use that to express the nesting. eg have a flat list of <backingStore> ordered by a depth first search, and then have <alias parent="foo" name="bar"/> to express the nesting. That would allow nesting info to be extracted for the few scenarios that actually need it, but keep the common case simple. > Implementation > ============== > The following APIs will be affected: > > defining domain XML (whether via define for persistent domains, or > create for transient domains): parse the new element. If the element is > already present, default to trusting the backing chain in that element > instead of reading from the disk files. If the element is absent, read > the disk files and populate the element. It is probably also worth > adding a flag to trigger validation mode: read the disk files to ensure > they match the xml, and refuse the operation if there is a mismatch (as > for updating xml to match reality, the simplest is to edit the XML and > delete the <backingStore> element then try the define again, so I don't > see the need for a flag for that action). > > I may also need to figure out if it is worth tainting a domain any time > where libvirt detects that the XML backing chain vs. the disk file read > backing chain have diverged. I don't think we want todo that - there are genuine use cases where that is a reasonable thing todo. eg you can provide a raw file to a guest and that guest may genuinely want to format the virtual disk it received with some other format. We don't want to taint such use cases. > dumping domain XML: always output the new element, by default without > consulting disk files. By tracking the chain in memory ever since the > guest is defined, it should already be available for output. I'm > debating whether we need a flag (similar to virsh dumpxml --update-cpu) > that can force libvirt to re-read the disk files at the time of the dump > and regenerate the chain to match reality of any changes made behind > libvirt's back. It feels like apps should just query the storage pool APIs if they want to fetch refreshed notion of backing file formats. > sVirt security labeling: right now, we are read the disk files to both > label and remove labels on a backing chain - obviously, once the chain > is tracked natively as part of the <disk>, we should be labeling without > having to read disk files We also likely want to be able to set labels in the XML against individual backing files too, so we're not unconditionally using a read-only label for backing files which may soon need write ability. Regards, 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