Red Hat Bugzilla – Bug 1177194
Fail to Migrate with Bridged network, eth + macvtap ,with different interface name on two hosts
Last modified: 2015-03-05 02:48:40 EST
description of problem: Fail to Migrate with Bridged network, eth + macvtap ,with different interface name on two hosts Version-Release number of selected component (if applicable): libvirt-1.2.8-11.el7.x86_64 How reproducible: 100% Steps to Reproduce: prepare two host .On both source and target host create a new network . NOTE , source and target host has different interface name . 1.on source host . 1.1 define and start a new network #cat vepa-network.xml <network> <name>vepa-net</name> <forward dev='eno1' mode='vepa'> <interface dev='eno1'/> </forward> </network> # virsh net-define vepa-network.xml # virsh net-start vepa-net # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active no yes vepa-net active no yes 1.2 start a guest with the following interface using vepa-net: ...... <interface type='network'> <mac address='52:54:00:1b:6f:e5'/> <source network='vepa-net'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> .... 2. on the target host . 2.1 define and start a new network ,using the same network name as source host #cat vepa-network.xml <network> <name>vepa-net</name> <==== note same network name <forward dev='enp2s0' mode='vepa'> <interface dev='enp2s0'/> </forward> </network> # virsh net-define vepa-network.xml # virsh net-start vepa-net # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active no yes vepa-net active no yes 3. migrate # virsh migrate --live r7 qemu+ssh://$ip/system error: Unable to get index for interface eno1: No such device Actual results: Fail to migrate . error: Unable to get index for interface eno1: No such device Expected results: Guest can migrate successfully . additional info: after start guest , dumpxml : # virsh dumpxml r7 | grep interface -A 9 <interface type='direct'> <==== it change to direct <mac address='52:54:00:15:f5:12'/> <source network='vepa-net' dev='eno1' mode='vepa'/> <==and set the dev <target dev='macvtap0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> this issue alao can produce when using private mode .
additional info : On RHEL7.0 . It can migrate successfully and the domain XML won't change between active and inactive status. version : libvirt-1.1.1-29.el7_0.4.x86_64 qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64 kernel-3.10.0-123.el7.x86_64 domain XML : active domain xml: # virsh dumpxml r7 | grep interface -A 8 <interface type='network'> <=== It will not be changed to direct <mac address='52:54:00:d9:99:2c'/> <source network='vepa-net'/> <=== no extra dev info <target dev='macvtap0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> inactive domain xml : # virsh dumpxml r7 --inactive | grep interface -A 8 <interface type='network'> <mac address='52:54:00:d9:99:2c'/> <source network='vepa-net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
Patch sent upstream for review: https://www.redhat.com/archives/libvir-list/2014-December/msg01013.html
Fixed upstream by v1.2.11-109-gdb19a4a: commit db19a4a3c6f72e464bc3ad00e904d8df13887382 Author: Luyao Huang <lhuang@redhat.com> Date: Thu Dec 25 11:38:00 2014 +0800 conf: Don't format actual network definition in migratable XML https://bugzilla.redhat.com/show_bug.cgi?id=1177194 When migrate a vm, we will generate a xml via qemuDomainDefFormatLive and pass this xml to target libvirtd. Libvirt will use the current network state in def->data.network.actual to generate the xml, this will make migrate failed when we set a network type guest interface use a macvtap network as a source in a vm then migrate vm to another host(which has the different macvtap network settings: different interface name, bridge name...) Add a flag check in virDomainNetDefFormat, if we set a VIR_DOMAIN_XML_MIGRATABLE flag when call virDomainNetDefFormat, we won't get the current vm interface state. Signed-off-by: Luyao Huang <lhuang@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Verify it as follows.The result is expected .Move its status to VERIFIED. # rpm -q libvirt libvirt-1.2.8-12.el7.x86_64 On source host # virsh net-dumpxml vepa-net <network connections='1'> <name>vepa-net</name> <uuid>78a038e7-dab9-4ce6-b63e-054031a22408</uuid> <forward dev='enp2s0' mode='vepa'> <interface dev='enp2s0' connections='1'/> </forward> </network> # virsh dumpxml r7a|grep interface -A6 <interface type='direct'> <mac address='52:54:00:0a:e5:15'/> <source network='vepa-net' dev='enp2s0' mode='vepa'/> <target dev='macvtap0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # virsh migrate --live r7a qemu+ssh://$targetip/system --persistent root@10.66.4.135's password: On target host # virsh list |grep r7a 48 r7a running # virsh net-dumpxml vepa-net <network connections='1'> <name>vepa-net</name> <uuid>db38469f-bb10-44e5-8ffe-384ddfec61bb</uuid> <forward dev='eno1' mode='vepa'> <interface dev='eno1' connections='1'/> </forward> </network> # virsh dumpxml r7a|grep interface -A6 <interface type='direct'> <mac address='52:54:00:0a:e5:15'/> <source network='vepa-net' dev='eno1' mode='vepa'/> <target dev='macvtap1'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # virsh dumpxml r7a --migratable|grep interface -A6 <interface type='network'> <mac address='52:54:00:0a:e5:15'/> <source network='vepa-net'/> <target dev='macvtap1'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> The guest also can successfully migrated in the opposite direction.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html