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.