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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list