DescriptionJaroslav Suchanek
2017-09-15 14:03:11 UTC
+++ This bug was initially created as a clone of Bug #1490482 +++
Description of problem:
This issue is seen during ACI-RHEV integration. unidirectional pings works from VM1 in RedHat Host1 to VM2 in RedHat Host2. The ping stops when the VM2 vNic is changed to a different network. Looks like linux bridge do not send RARP when a vNIC is brought up in a VLAN.The ACI TOR has learned about the MAC of this VM in previous network(VLAN).
In the case of VMWare DVS, Cisco DVS there will be RARP packets being sent from virtual switch on hypervisor, which updates switches about reachability of this MAC in new VLAN.
Version-Release number of selected component (if applicable):
How reproducible:
Easily reproducible
Steps to Reproduce:
1. Do a unidirectional ping from VM1 to VM2 between two Redhat virtualization hosts.
2. Change the vNic of VM2 to a different network
3. Ping stops
Actual results:
Expected results:
Additional info:
--- Additional comment from Laine Stump on 2017-09-12 15:59:49 CEST ---
This is assigned to libvirt, but there isn't enough information in the description to understand what it is that libvirt is alleged to be doing or not doing (or what it *should* be doing), nor any particulars about the configuration.
The problem statement talks about "Linux bridges", but also about VLANs. Since there is no support within libvirt for transparently setting VLANs of guest interfaces attached to a Linux Host Bridge, I assume that this setup is using Open vSwitch, but there's no mention of that here.
Also, it says that "VM2 vNIC is moved to a different network". I'm *guessing* that this means that the guest interface remains connected to the same bridge, but that its VLAN changes - is that correct? Where are you changing the VLAN tag? In the guest (VM) itself? Of is your bridge an OVS bridge, and you're changing the VLAN tag transparent to the guest? If so, how?
Can you provide configuration (RHV config would be useful for a RHV networking person, but for libvirt we would really appreciate libvirt XML) to describe the setup, and the exact commands you use (and on which machine) to change the VLAN tag?
--- Additional comment from on 2017-09-15 01:59:31 CEST ---
From the ACI, we are creating networks. These networks are pushed to the RHEV Manager. Each network will have a vlan. In the RHEV Manager, When the vNIC of the VM is attached to the network, we expect RARP to be sent out by the linux bridge created for this network(VLAN).
vNIC vlan change is done from the RHEV Manager by selecting the VM's vNIC and assigning a particular network. The vlan change is done in the VM itself from the RHEV Manager.
libvirt xmls attached.
--- Additional comment from on 2017-09-15 02:00:17 CEST ---
From the ACI, we are creating networks. These networks are pushed to the RHEV Manager. Each network will have a vlan. In the RHEV Manager, When the vNIC of the VM is attached to the network, we expect RARP to be sent out by the linux bridge created for this network(VLAN).
vNIC vlan change is done from the RHEV Manager by selecting the VM's vNIC and assigning a particular network. The vlan change is done in the VM itself from the RHEV Manager.
libvirt xmls attached.
--- Additional comment from on 2017-09-15 02:01:22 CEST ---
qemu networks is a tgz archive
--- Additional comment from on 2017-09-15 02:01:35 CEST ---
qemu networks is a tgz archive
--- Additional comment from Laine Stump on 2017-09-15 15:45:29 CEST ---
The libvirt network configs show that these are standard Linux host bridges, so libvirt isn't involved in any setting of VLAN tags. Based on the description, the change in networks is being initiated by RHV, which I think is using vdsm to change the VLAN tag (it sounds like maybe it is sending a command to the guest OS via a guest agent? Not sure, since I'm unfamiliar with the details of RHV and vdsm). I don't really think there is anything to be done about this problem at the layer of libvirt.
Dan K.: I'm not sure what is the correct place to assign this BZ, since the RHV and vdsm versions aren't known, and also because the Product vs. Component matrix in bugzilla seems mixed up (it's possible to assign to a *Product* called vdsm, and also to a *Component* called vdsm that is under the "Red Hat Enterprise Virtualization Manager" Product. I don't want to accidentally assign it to the wrong place and have it lost, so can you please put it in the right place?
Thanks!