libvirt/src/libvirt_macvtap.syms

#

# macvtap.h
delMacvtap;
openMacvtapTap;
virVMOperationTypeFromString;
virVMOperationTypeToString;
vpAssociatePortProfileId;
vpDisassociatePortProfileId;
macvtap support for libvirt -- build support This patch adds build support for libvirt checking for certain contents of /usr/include/linux/if_link.h to see whether macvtap support is compilable on that system. One can disable macvtap support in libvirt via --without-macvtap passed to configure. * configure.ac src/Makefile.am: new build support * src/libvirt_macvtap.syms: list of exported symbols * src/util/macvtap.c: empty module to not break compilation 2010-02-12 17:03:07 +00:00			`#`

			`# macvtap.h`
macvtap teardown rework Rework and simplification of teardown of the macvtap device. Basically all devices with the same MAC address and link device are kept alive and not attempted to be torn down. If a macvtap device linked to a physical interface with a certain MAC address 'M' is to be created it will automatically fail if the interface is 'up'ed and another macvtap with the same properties (MAC addr 'M', link dev) happens to be 'up'. This will prevent the VM from starting or the device from being attached to a running VM. Stale interfaces are assumed to be there for some reason and not stem from libvirt. In the VM shutdown path, it's assuming that an interface name is always available so that if the device type is DIRECT it can be torn down using its name. * src/util/macvtap.h src/libvirt_macvtap.syms: change of deleting routine * src/util/macvtap.c: cleanups and change of deleting routine * src/qemu/qemu_driver.c: change cleanup on shutdown * src/qemu/qemu_conf.c: don't delete Macvtap in qemudPhysIfaceConnect() 2010-02-18 14:13:48 +00:00			`delMacvtap;`
802.1Qbg: use pre-associate state at beginning of inc. migr This patch introduces the usage of the pre-associate state of the IEEE 802.1Qbg standard on incoming VM migration on the target host. It is in response to bugzilla entry 632750. https://bugzilla.redhat.com/show_bug.cgi?id=632750 For being able to differentiate the exact reason as to why a macvtap device is being created, either due to a VM creation or an incoming VM migration, I needed to pass that reason as a parameter from wherever qemudStartVMDaemon is being called in order to determine whether to send an ASSOCIATE (VM creation) or a PRE-ASSOCIATE (incoming VM migration) towards lldpad. I am also fixing a problem with the virsh domainxml-to-native call on the way. Gerhard successfully tested the patch with a recent blade network 802.1Qbg-compliant switch. The patch should not have any side-effects on the 802.1Qbh support in libvirt, but Roopa (cc'ed) may want to verify this. 2010-11-30 17:50:54 +00:00			`openMacvtapTap;`
			`virVMOperationTypeFromString;`
			`virVMOperationTypeToString;`
			`vpAssociatePortProfileId;`
			`vpDisassociatePortProfileId;`