[libvirt-users] exposing <actual> [was: QEMU hook on restore]
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)