[libvirt] [PATCH 6/7] conf: output actual netdev status in <interface> XML

[Daniel P. Berrange]

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 :|