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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list