mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-03-20 07:59:00 +00:00
Until now, the "live" XML status of an <interface type='network'> device would always show the network information, rather than the exact hardware device that was used. It would also show the name of any portgroup the interface belonged to, rather than providing the configuration that was derived from that portgroup. As an example, given the following network definition: [A] <network> <name>testnet</name> <forward type='bridge' dev='p4p1_0'> <interface dev='p4p1_0'/> <interface dev='p4p1_1'/> <interface dev='p4p1_2'/> <interface dev='p4p1_3'/> </forward> <portgroup name='admin'> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> </portgroup> </network> and the following domain <interface>: [B] <interface type='network'> <source network='testnet' portgroup='admin'/> </interface> the output of "virsh dumpxml $domain" while the domain was running would yield something like this: [C] <interface type='network'> <source network='testnet' portgroup='admin'/> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> In order to learn the exact bandwidth information of the interface, a management application would need to retrieve the XML for testnet, then search for the portgroup named "admin". Even worse, there was no simple and standard way to learn which host physdev the macvtap0 device is attached to. Internally, libvirt has always kept this information in the virDomainDef that is held in memory, as well as storing it in the (libvirt-internal-only) domain status XML (in /var/run/libvirt/qemu/$domain.xml). In order to not confuse the runtime "actual state" with the config of the device, it's internally stored like this: [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). Now we have a need for this information to 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 /var/run/libvirt/qemu/$domain.xml - that remains the same so that there is no loss of information). That is what this patch does - once 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. An example of where this could cause problems is in virt-manager's network device display, which shows the status of the device, but allows you to edit that status info and save it as the new config. Previously virt-manager would always display the information in example [C] above, and allow editing that. With this patch, it will instead display what is in [E] and allow editing it directly, which could lead to some confusion. I would suggest that virt-manager have an "edit" button which would change the display from the "live" xml to the "inactive" xml, so that editing would be done on that; such a change would both handle the new situation, and also be compatible with older releases.
LibVirt : simple API for virtualization Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). It is free software available under the GNU Lesser General Public License. Virtualization of the Linux Operating System means the ability to run multiple instances of Operating Systems concurrently on a single hardware system where the basic resources are driven by a Linux instance. The library aim at providing long term stable C API initially for the Xen paravirtualization but should be able to integrate other virtualization mechanisms if needed. Daniel Veillard <veillard@redhat.com>
Description
Libvirt provides a portable, long term stable C API for managing the
virtualization technologies provided by many operating systems. It
includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
Hypervisor.
Languages
C
95.1%
Python
2%
Meson
0.9%
Shell
0.6%
Perl
0.5%
Other
0.8%