On 02/10/2012 02:12 PM, Laine Stump wrote: > I think if it's going to be turned on, it can just be included in any > output of live xml. > > One potential problem with this is that, as it stands, someone wanting > to know, e.g., which ethernet device a guest interface is connected to > with macvtap will need to look in two places - 1) if there is no > <actual> element, then it will be in <source dev='ethX'/> under the main > interface element, but if there *is* an <actual>, then it's <source > dev='ethX'/> under <actual>. (In other words, if the original interface > type isn't 'network', then <actual> won't be filled in. The question > then is whether or not we *want* it filled in.) Good point - making a user search two places isn't very convenient. > > An alternate implementation would be to write live XML to the public API > as if the interface config acquired from the network definition had been > hand-configured. > > (basically moving everything in <actual> up to <interface>). This would > make it easier for people trying to do report status kinds of things, > and the loss of original config data wouldn't be a problem here, but I > don't know if that would be an acceptable practice. I don't like that as the default action. Too many people do 'virsh dumpxml' on a live machine, then use that as the template to configure a new machine, and collapsing the <actual> into the configured portion means that use of the XML as a template would create a different result next time (tying the interface to one port, rather than leaving it associated with a network pool). But under the control of a flag, that sounds nice. Maybe that argues for this approach: dumpxml, flags == 0 => output <actual>, user must search two places dumpxml, flags == DUMP_ACTUAL => rewrite XML to merge actual into the configuration slot, so that user only has to search one place -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
