Re: [libvirt] RFC: Exposing backing chains in <domain> XML
On 03/14/2014 05:07 AM, Daniel P. Berrange wrote:
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.
Evidence that the storage volume and domain disk descriptions were not
originally designed to be shared, although we certainly want to get to
that point.
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.
Might work, but how does it express Rich's case where we know _part_ of
a chain? If the linear list of backing files is not present, it's
obvious that libvirt should populate it; but if the linear list contains
only one element, how do we distinguish between the user telling us the
amount of the chain the explicitly know while expecting us to probe the
remainder of the chain, vs. the user telling us the entire chain and
requesting that we probe no further?
We're still at the stage where getting the XML right is important, and
before it affects too much of the code I'm working on first (that is, I
can go ahead and code the split into a new structure in src/util that
represents everything we need for an XML element of a single backing
chain element, whether or not we then choose to have a tree or a flat
array of those structures).
> 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.
No, if libvirt knows that you handed the disk to the guest as raw, then
libvirt will always treat it as raw, rather than probing to see what the
guest has done with that storage. It is only in the case where you hand
storage to the guest without also specifying the storage format where
probing becomes an issue.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 604 bytes)