[ovs-discuss] Re : OVS and KVM: getting persistent UUID's or querying UUID values based on interface name
darkbls at yahoo.com
Wed Jun 30 13:15:03 UTC 2010
Are you saying that a VM interface (tap0 for exemple) are connected to both bridge or you have a tap0 on the bridge dedicated to guest network and a tap1 on the bridge dedicated for SPAN monitor ?
----- Message d'origine ----
De : Sean Brady <sbrady at gtfservices.com>
À : "discuss at openvswitch.org" <discuss at openvswitch.org>
Envoyé le : Mer 23 juin 2010, 21h 29min 48s
Objet : [ovs-discuss] OVS and KVM: getting persistent UUID's or querying UUID values based on interface name
I am trying to implement a SPAN port in combination with a KVM guest as a SPAN monitor. I have two bridges set up, one for guest network and the other for the SPAN port, in conjunction with a dedicated NIC port for each bridge (eth1 for guest networking and eth2 for SPAN). I have the physical switch connected to eth2 sending SPAN output to this dedicated network port (eth2). I have it working by using modifying the OVS database's mirror table to mirror traffic from the dedicated SPAN NIC to the virtual port connected to the VM.
In KVM when a VM is shutdown, the virtual interface is deleted, and when the VM is started back up, a new interface is created by libvirt and added to (both) bridges. The issue is that when the new interface is created, it gets a new UUID, which of course will need to be added back into the mirror table as the output_port.
Is there any way to get UUID persistence for these virtual interfaces? If not, is there a clean way to query the DB to get the UUID of a named port? If I could just consistently get the UUID of the port using a shell script I can have this working when the VM is started up.
Thanks for your help.
P.S.: I am working on documenting this out, as well as my steps for using bridging with OVS and KVM. If we decide it's helpful I am more than happy to contribute it.
discuss mailing list
discuss at openvswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss