Red Hat Bugzilla – Bug 890265
change the mac of virtio_net device temporary but will effect forever after reboot guest
Last modified: 2013-11-21 01:27:35 EST
Description of problem: boot guest with virtio_net device w/o vhost(vhost=on or vhost=off can hit this issue), and change the mac address via 'ifconfig ethX hw ether $new_mac' and check it, and then reboot guest to check it. the mac of virtio_net will effect forever in guest, and the mac will be changed in monitor via 'info network'. BTW, the e1000 and rtl8139 have no such issue. Version-Release number of selected component (if applicable): host info: kernel-2.6.32-351.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64 guest info: rhel6.4 64bit kernel-2.6.32-351.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1.boot guest with virtio_net device with vhost=on. eg:...-netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=34:40:B5:9E:D3:90,bus=pci.0,addr=0x5 (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:90 peer=hostnet0 # ifconfig | grep HWaddr eth1 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:90 2.change the mac address via 'ifconfig ethX hw ether $new_mac' in guest. # ifconfig eth1 hw ether 34:40:B5:9E:D3:80 3.check the mac and see if guest still can receive packets. (qemu) info network # ifconfig | grep HWaddr # ping -c 5 www.baidu.com 4.reboot guest and check it. (qemu) info network # ifconfig | grep HWaddr # ping -c 5 www.baidu.com Actual results: after step 3, the mac of virtio-net can be changed correctly and work well, but the mac of virtio-net in monitor was changed. (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:80 peer=hostnet0 (qemu) # ifconfig | grep HWaddr eth1 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:80 # ping -c 5 www.baidu.com PING www.a.shifen.com (220.181.111.147) 56(84) bytes of data. 64 bytes from 220.181.111.147: icmp_seq=1 ttl=50 time=5.47 ms 64 bytes from 220.181.111.147: icmp_seq=2 ttl=50 time=12.6 ms 64 bytes from 220.181.111.147: icmp_seq=3 ttl=50 time=9.11 ms 64 bytes from 220.181.111.147: icmp_seq=4 ttl=50 time=5.10 ms 64 bytes from 220.181.111.147: icmp_seq=5 ttl=50 time=5.09 ms --- www.a.shifen.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4011ms rtt min/avg/max/mdev = 5.093/7.480/12.606/2.977 ms after step 4, the mac of virtio-net was changed effectively after reboot guest. (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:80 peer=hostnet0 (qemu) # ifconfig | grep HWaddr eth4 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:80 # ping -c 5 www.baidu.com PING www.a.shifen.com (220.181.111.147) 56(84) bytes of data. 64 bytes from 220.181.111.147: icmp_seq=1 ttl=50 time=5.47 ms 64 bytes from 220.181.111.147: icmp_seq=2 ttl=50 time=5.02 ms 64 bytes from 220.181.111.147: icmp_seq=3 ttl=50 time=5.04 ms 64 bytes from 220.181.111.147: icmp_seq=4 ttl=50 time=5.08 ms 64 bytes from 220.181.111.147: icmp_seq=5 ttl=50 time=7.53 ms --- www.a.shifen.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4013ms rtt min/avg/max/mdev = 5.025/5.633/7.530/0.965 ms Expected results: 1.the mac address of virtio-net in monitor should not be changed. (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:80 peer=hostnet0 <------macaddr=34:40:b5:9e:d3:90 (qemu) 2.the mac of virtio-net should not be changed effectively after reboot guest, it should return back to the primary mac(34:40:b5:9e:d3:90). Additional info:
commit 41dc8a67c7dcecdf7ae1cd25db3c46f2b42a221f Author: Michael S. Tsirkin <mst@redhat.com> Date: Wed Jan 16 11:37:40 2013 +0200 virtio-net: revert mac on reset Once guest overrides virtio net primary mac, it retains the value set until qemu exit. This is inconsistent with standard nic behaviour. To fix, revert the mac to the original value on reset. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fixed upstream, need to backport, not worth a 6.5 exception.
Referring to https://bugzilla.redhat.com/show_bug.cgi?id=1002797#c17
Hi, Ademar Mike said this bug blocks whql testing (similar with bug 1002797, not sure whether they are same bug), so could we fix this asap in rhel6.5? Thanks, Qunfang
scratch build: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6292176 pls update BZ on whether this fixes the issue.
yes HMP is messed up (upstream too) I sent a patch. http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6292458
*** Bug 1002797 has been marked as a duplicate of this bug. ***
Verify this issue on qemu-kvm-406 verision that has fixed it correctly. the mac of virtio-net can return back to the primary mac(34:40:b5:9e:d3:90) value after reboot guest. host info: # uname -r && rpm -q qemu-kvm-rhev 2.6.32-420.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.406.el6.x86_64 guest info: 2.6.32-420.el6.x86_64 Steps: the same to comment #0 Results: 1.before change the mac address: (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:90 peer=hostnet0 guest]# ifconfig | grep HWaddr eth3 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:90 # ifconfig | grep HWaddr eth1 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:90 # ping -c 5 www.baidu.com PING www.a.shifen.com (220.181.112.143) 56(84) bytes of data. 64 bytes from 220.181.112.143: icmp_seq=1 ttl=51 time=7.38 ms 64 bytes from 220.181.112.143: icmp_seq=2 ttl=51 time=9.10 ms 64 bytes from 220.181.112.143: icmp_seq=3 ttl=51 time=5.30 ms 64 bytes from 220.181.112.143: icmp_seq=4 ttl=51 time=6.20 ms 64 bytes from 220.181.112.143: icmp_seq=5 ttl=51 time=9.06 ms --- www.a.shifen.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4014ms rtt min/avg/max/mdev = 5.303/7.411/9.106/1.519 ms 2.after change the mac address: guest]# ifconfig eth1 hw ether 34:40:B5:9E:D3:80 guest]# ifconfig | grep HWaddr eth1 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:80 guest]# ping -c 5 www.baidu.com PING www.a.shifen.com (220.181.111.148) 56(84) bytes of data. 64 bytes from 220.181.111.148: icmp_seq=1 ttl=51 time=16.4 ms 64 bytes from 220.181.111.148: icmp_seq=2 ttl=51 time=8.80 ms 64 bytes from 220.181.111.148: icmp_seq=3 ttl=51 time=7.69 ms 64 bytes from 220.181.111.148: icmp_seq=4 ttl=51 time=5.18 ms 64 bytes from 220.181.111.148: icmp_seq=5 ttl=51 time=11.2 ms --- www.a.shifen.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4017ms rtt min/avg/max/mdev = 5.182/9.876/16.429/3.818 ms (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:80 peer=hostnet0 3.after reboot guest: guest]# ifconfig | grep HWaddr eth1 Link encap:Ethernet HWaddr 34:40:B5:9E:D3:90 guest]# ping -c 5 www.baidu.com PING www.a.shifen.com (220.181.112.143) 56(84) bytes of data. 64 bytes from 220.181.112.143: icmp_seq=1 ttl=51 time=7.85 ms 64 bytes from 220.181.112.143: icmp_seq=2 ttl=51 time=16.9 ms 64 bytes from 220.181.112.143: icmp_seq=3 ttl=51 time=11.7 ms 64 bytes from 220.181.112.143: icmp_seq=4 ttl=51 time=7.92 ms 64 bytes from 220.181.112.143: icmp_seq=5 ttl=51 time=5.23 ms --- www.a.shifen.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4011ms rtt min/avg/max/mdev = 5.237/9.938/16.980/4.081 ms (qemu) info network Devices not on any VLAN: hostnet0: ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown peer=virtio-net-pci0 virtio-net-pci0: model=virtio-net-pci,macaddr=34:40:b5:9e:d3:90 peer=hostnet0 Base on above, move to VERIFIED status, please correct me if any mistake. Best Regards, sluo
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. http://rhn.redhat.com/errata/RHSA-2013-1553.html