Comment 4 for bug 1812822

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I used a recent version of the softwrae stack from Disco
- qemu 3.1
- libvirt 5.0
- openvswitch 2.11

With that I had a guest with an OVS device like that:
    <interface type='bridge'>
      <mac address='52:54:00:22:57:fd'/>
      <source network='ovsbr0' bridge='ovsbr0'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='f44ac4e9-fe46-48b8-920c-7ba13dd024ba'/>
      </virtualport>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <driver name='vhost' queues='4'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>

Not too different to your's I'd think.
The OVS is trivial just having this interface atm.

$ sudo ovs-vsctl show
596674ef-e4cd-471f-9708-9caa5737961c
    Bridge "ovsbr0"
        Port "eno49"
            Interface "eno49"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vnet1"
            Interface "vnet1"
    ovs_version: "2.11.0"

$ ip link show dev vnet1
93: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:22:57:fd brd ff:ff:ff:ff:ff:ff

I have a started a second guest on the same vswitch (to check traffic from the first guest later on).

Now lets delete that port:
$ sudo ovs-vsctl del-port ovsbr0 vnet1
$ sudo ovs-vsctl show
596674ef-e4cd-471f-9708-9caa5737961c
    Bridge "ovsbr0"
        Port "vnet3"
            Interface "vnet3"
        Port "eno49"
            Interface "eno49"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
    ovs_version: "2.11.0"

Ok the OVS device is gone.
Obviously traffic on that interface is dead now, but the guest is still alive and happy.

The host dev is still there:
$ ip link show dev vnet1
93: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:22:57:fd brd ff:ff:ff:ff:ff:ff
Removing that as well as suggested

$ sudo ip link del vnet1
$ ip link show dev vnet1
Device "vnet1" does not exist.

The guest still is up and running, while traffic still won't work for obvious reasons.
Now lets trigger the hot-unplug of the device.

$ virsh detach-device guest-openvswitch-1 net.xml
Device detached successfully

The guest is still happy and alive.
It lost the device (since we detached it) but that is ok and intentional.