6:07 a.m.
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 :|