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