Bug 922589 - e1000/rtl8139: qemu mac address can not be changed via set the hardware address in guest
Summary: e1000/rtl8139: qemu mac address can not be changed via set the hardware addre...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1300626
TreeView+ depends on / blocked
 
Reported: 2013-03-18 02:19 UTC by mazhang
Modified: 2016-09-20 04:41 UTC (History)
9 users (show)

Fixed In Version: qemu-kvm-1.5.3-17.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1300626 (view as bug list)
Environment:
Last Closed: 2014-06-13 10:24:00 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description mazhang 2013-03-18 02:19:27 UTC
Description of problem:
RHEL7 guest , change mac address in guest, but check the nic address in qemu monitor, it did not changed, e1000 and rtl8139 met this issue, virtio-net-pci did not.

Version-Release number of selected component (if applicable):
host: RHEL7 Alpha3
kernel: 3.8.0-0.40.el7.x86_64
qemu: qemu-kvm-1.4.0-1.el7.x86_64

guest: RHEL7 Alpha3
kernel: 3.8.0-0.40.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot a guest with:
-netdev tap,id=hostnet0,downscript=no,vhost=on -device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:2e:28:1c,bus=pci.0,addr=0x4,bootindex=3

2.Change mac address in guest
#ifconfig eth0 hw ether 00:1a:4a:2e:11:11

3.Check the mac address in guest and qemu monitor

Actual results:
1 mac address changed in guest:
...
ether 00:1a:4a:2e:11:11  txqueuelen 1000  (Ethernet)
...

2 mac address didn't changed in qemu monitor:
(qemu) info network
net0: index=0,type=nic,model=e1000,macaddr=00:1a:4a:2e:28:1c
 \ hostnet0: index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=no

Expected results:
mac address changed in qemu monitor

Additional info:

Comment 2 Hai Huang 2013-03-19 13:07:17 UTC
Please reassign/dispatch as appropriate. Thanks.

Comment 3 Amos Kong 2013-03-20 02:27:27 UTC
This bug is already in my todo list, I touched it when I worked on virtio-net mac programming. Qemu never updates network info after guest changes mac of e1000. I will solve it.

Comment 4 Qian Guo 2013-03-26 07:19:53 UTC
Windows Server 2012 guest, w/ virtio-net-pci, hit this problem, so update this case.

Comment 5 Amos Kong 2013-10-17 07:09:43 UTC
(In reply to Qian Guo from comment #4)
> Windows Server 2012 guest, w/ virtio-net-pci, hit this problem, so update
> this case.

Please file a new bug for virtio-win

Comment 6 Amos Kong 2013-10-17 07:10:51 UTC
Posted patches to fix rtl8139 & e1000

http://marc.info/?l=qemu-devel&m=138199340525029&w=2

Comment 7 Qian Guo 2013-10-17 07:38:42 UTC
(In reply to Amos Kong from comment #5)
> (In reply to Qian Guo from comment #4)
> > Windows Server 2012 guest, w/ virtio-net-pci, hit this problem, so update
> > this case.
> 
> Please file a new bug for virtio-win

Test this with components:
# uname -r
3.10.0-34.el7.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-1.5.3-9.el7.x86_64

and a 32bit windows8.1 guest with virtio-win-prewhql-72 installed, not hit such issue:

1.Boot guest with virtio-net-pci:
..-netdev tap,id=netdev0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,mac=00:1b:21:7a:16:10,netdev=netdev0 ...

2.change mac inside guest to 020202020202
3.Under hmp:
(qemu) info network
virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=02:02:02:02:02:02
 \ netdev0: index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown

so according to above, not hit this issue, won't file such bug

Comment 8 Qian Guo 2013-10-17 08:20:43 UTC
And test with windows 2012 64bit, installed virtio-win-prewhql-72, not hit such issue, step and result are same as comment #7

Comment 9 Miroslav Rezanina 2013-11-07 15:55:56 UTC
Fix included in qemu-kvm-1.5.3-17.el7

Comment 10 Miroslav Rezanina 2013-11-07 15:57:17 UTC
Fix included in qemu-kvm-1.5.3-17.el7

Comment 12 Qian Guo 2013-11-28 08:32:52 UTC
Reproduced by qemu-kvm-1.5.3-9.el7.x86_64
Steps:
1.Boot a RHEL7 guest:
# /usr/libexec/qemu-kvm -M pc -cpu Penryn -enable-kvm -m 4096 -smp 4,socket=1,cores=4,threads=1 -name rhel7 -nodefaults -nodefconfig -drive file=/home/rhel7base.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,werror=stop,rerror=stop,aio=native -device virtio-scsi-pci,id=virtio-disk0 -device scsi-hd,bus=virtio-disk0.0,drive=drive-virtio-disk0,id=scsi-hd -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -vnc :10 -vga std -monitor stdio -boot menu=on -netdev tap,id=netdev0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device e1000,mac=0a:ae:4e:1e:d1:4a,netdev=netdev0,id=net0  -qmp tcp:0:5555,server,nowait

2.Under hmp, check the mac address
(qemu) info network
net0: index=0,type=nic,model=e1000,macaddr=0a:ae:4e:1e:d1:4a
 \ netdev0: index=0,type=tap,ifname=tap0,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown


3.Inside guest, change mac address:
#ifconfig eth0 hw ether 0a:ae:4e:1e:d1:01

Result:
Under hmp, re-check the mac address:
net0: index=0,type=nic,model=e1000,macaddr=0a:ae:4e:1e:d1:4a
 \ netdev0: index=0,type=tap,ifname=tap0,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown

the mac address is not changed, so this bug is reproduced by qemu-kvm-1.5.3-9.el7.x86_64

Verify this bug with qemu-kvm-1.5.3-19.el7.x86_64

Steps as above,
Result: after change mac address inside guest, re-check the mac address under hmp:

(qemu) info network
net0: index=0,type=nic,model=e1000,macaddr=0a:ae:4e:1e:d1:01
 \ netdev0: index=0,type=tap,ifname=tap0,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown

The mac address is set as the new one as changed inside guest.

So, according to above, this bug is fixed by qemu-kvm-1.5.3-19.el7.x86_64.

Comment 14 Ludek Smid 2014-06-13 10:24:00 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.