On 05/13/2016 08:24 PM, Richard Harman wrote:

On 05/13/16 20:04, Laine Stump wrote:

...

On 05/13/2016 09:57 AM, Richard Harman wrote:

...

I've debugged this, and I think the interfaceid stuff in network XML isn't doing much besides setting a custom interfaceid in an OpenVSwitch table that really has no effect on the operation of OpenVSwitch. I think the -- set Interface vnet0 "external-ids:iface-id="{uuid here}" command run by libvirt doesn't actually set the _uuid of a new interface. :( I don't use Open vSwitch, but I was around when the support was added, and reviewed the patches (which were authored by Kyle Mestery, whose email has changed since then, so I'm not sure how to Cc him). My understanding at the time was that the interfaceid was intended for exactly the purpose that you say doesn't work (i.e. so that OVS itself could recognize that interface as it appeared and disappeared at different locations on the network). I would classify that as a bug, but that's just my understanding as an OVS outsider.

Further evidence, now that I figured out how to dump the external-ids stuff in OVS:

Here's the relevant ports of the domain XML:

<domain type='kvm' id='5'> <name>cuckoo</name> <uuid>cb4903aa-eaf4-432d-aa57-e9f74f1c8b79</uuid> .... <interface type='bridge'> <mac address='52:54:00:f5:29:72'/> <source network='malware' bridge='malware0'/> <virtualport type='openvswitch'> <parameters interfaceid='23e982f3-f344-48a2-8bed-b584acb95616'/> </virtualport> <target dev='monitor0'/> <model type='virtio'/> <alias name='net2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface> ....

cuckoo vm up: monitor0 _uuid is 969ef76c...

# ovs-vsctl --columns=name,_uuid,external-ids list Interface | grep -A3 monitor0 name : "monitor0" _uuid : 969ef76c-c802-4e9f-97e0-9a06ce133252 external_ids : {attached-mac="52:54:00:f5:29:72", iface-id="23e982f3-f344-48a2-8bed-b584acb95616", iface-status=active, vm-id="cb4903aa-eaf4-432d-aa57-e9f74f1c8b79"} #

cuckoo vm down: (no output, the interface has been deleted by libvirt)

# ovs-vsctl --columns=name,_uuid,external-ids list Interface | grep -A3 monitor0 #

I found this in my log, showing libvirt deleted the interface: ovs-vsctl[4590]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port monitor0

cuckoo vm up again: uuid is now fb025df0...

# ovs-vsctl --columns=name,_uuid,external-ids list Interface | grep -A3 monitor0 name : "monitor0" _uuid : fb025df0-d934-46d6-b9ed-314bc1de5ef3 external_ids : {attached-mac="52:54:00:f5:29:72", iface-id="23e982f3-f344-48a2-8bed-b584acb95616", iface-status=active, vm-id="cb4903aa-eaf4-432d-aa57-e9f74f1c8b79"} #

Anyway, thanks for reading! Hopefully we'll get to the bottom of this, where I can keep my span port. :) In the mean time I'm going to go digging through the OVS source, specifically the ovs-vsctl command to see if an argument can be used to forcibly set the internal _uuid in OVS.

Right. Either the ovs-vsctl command used by libvirt needs to change, or (if it's actually a bug in OVS) ovs-ctl's use of external-ids:iface-id needs to change. I'm Cc'ing libvir-list, just in case there's an OVS person who monitors that list but not this one.