On Fri, Feb 21, 2014 at 03:58:21PM +0200, Laine Stump wrote:
[D]
<interface type='network'>
<source network='testnet' portgroup='admin'/>
<actual type='direct'>
<source dev='p4p1_0' mode='bridge'/>
<bandwidth>
<inbound average='1000' peak='5000'
burst='1024'/>
<outbound average='128' peak='256' burst='256'/>
</bandwidth>
</actual>
<target dev='macvtap0'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
This was never exposed outside of libvirt though, because I thought it
would be too awkward for a management application to need to look in
two places for the same information, but I also wasn't sure that it
would be okay to overwrite the config info (in this case "<source
network='testnet' portgroup='admin'/>") with the actual runtime
info
(everything inside <actual> above).
Yep, it would be somewhat tedious for applications if they had to
look in two places for the same info, depending on whether the guest
was directly configured with type=direct vs indirectly configured
with type=direct via type=network.
Now the time has come that this information must be made available
to
management applications (in particular, so that a network "plugged"
hook will have full information about the device that is being plugged
in), so it's time to take the leap and decide that it is acceptable
for the config info to be replaced with actual runtime state (but
*only* when reporting domain live status, *not* when saving state in
/etc/libvirt/qemu/$domain.xml - that remains the same so that there is
no loss of information). That is what this patch does. With this patch
applied, the output of "virsh dumpxml $domain" when the domain is
running will contain something like this:
[E]
<interface type='direct'>
<source dev='p4p1_0' mode='bridge'/>
<bandwidth>
<inbound average='1000' peak='5000' burst='1024'/>
<outbound average='128' peak='256' burst='256'/>
</bandwidth>
<target dev='macvtap0'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
In effect, everything that is internally stored within <actual> is
moved up a level to where a management application will expect
it. This means that the management application will only look in a
single place to learn - the type of interface in use, the name of the
physdev (if relevant), the <bandwidth>, <vlan>, and <virtualport>
settings in use.
The potential downside is that a management app looking at this output
will not see that the physdev 'p4p1_0' was actually allocated from the
network named 'testnet', or that the bandwidth numbers were taken from
the portgroup 'admin'. However, if they are interested in that info,
they can always get the "inactive" XML for the domain.
So our normal practice with the guest domain XML has been that
the live XML should reflect the state of the running guest.
Apps wanting to see the offline state must always request the
inactive XML via VIR_DOMAIN_XML_INACTIVE.
cf tap device names, VNC ports, etc
The only case where this doesn't work is if the app has further
changed the inactive XML since they started the guest. I think it
is reasonable to say that if they're doing that, they understand
the consequences and if they really care about the original inactive
XML they'd have kept a record of it themselves.
The other mitigating thing about this proposed change is that the
proposed "new" syntax is a syntax that applications already know
how to parse, so we aren't likely to break application XML parsers
in doing this - at least not unless they were already broken :-)
So I think this is an ACK to the change, since it brings this into
line with our normal practice.
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 :|