Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 884450

Summary: after change mac address of guest, mouse inside guest can not be used after system_reset in qemu
Product: Red Hat Enterprise Linux 6 Reporter: Qian Guo <qiguo>
Component: qemu-kvmAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 6.4CC: acathrow, akong, areis, bsarathy, chayang, dyasny, juzhang, minovotn, mkenneth, tlavigne, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.348.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 07:45:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
just boot the rhel6.4 guest in X Winodw
none
after system_reset in qemu, catch the logs none

Description Qian Guo 2012-12-06 09:50:43 UTC 
Description of problem:
In guest, when change the mac address of nic. Under qemu, do system_reset, after guest boot up, mouse inside guest could not be used.


Version-Release number of selected component (if applicable):
1.
host# uname -r
2.6.32-345.el6.x86_64

host# rpm -qa\*openvswitch\*
openvswitch-controller-1.7.1-7.el6.x86_64
openvswitch-debuginfo-1.7.1-7.el6.x86_64
openvswitch-1.7.1-7.el6.x86_64

host#rpm -qa \*qemu\*
qemu-kvm-debuginfo-0.12.1.2-2.337.el6.x86_64
gpxe-roms-qemu-0.9.7-6.9.el6.noarch
qemu-img-0.12.1.2-2.337.el6.x86_64
qemu-kvm-0.12.1.2-2.337.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.337.el6.x86_64
qemu-guest-agent-0.12.1.2-2.337.el6.x86_64


2.
guest#host#uname -r
2.6.32-345.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a guest like this
/usr/libexec/qemu-kvm -cpu SandyBridge -m 2G -smp 2,sockets=1,cores=2,threads=1 -M rhel6.4.0 -enable-kvm -name testnic2 -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/test2.raw,if=none,format=raw,werror=stop,rerror=stop,cache=none,media=disk,id=drive-scsi0-disk0 -device virtio-scsi-pci,id=scsi0,addr=0x4 -device scsi-hd,scsi-id=0,lun=0,bus=scsi0.0,drive=drive-scsi0-disk0,id=virtio-disk0,bootindex=1 -nodefaults -nodefconfig -monitor stdio -netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-net-pci,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01  -vnc :10 -vga std

2.after it bootup in X window, do 
(qemu) info mice
* Mouse #1: vmmouse
  Mouse #0: QEMU PS/2 Mouse


3.inside guest, change the mac like this
#ifconfig eth0 down && ifconfig eth0 hw ether 54:52:1a:32:b4:01 && ifconfig eth0 up

4.in qemu do
(qemu)system_reset

Actual results:
when guest boot up, the mouse could not be used either in x window or testmode

Expected results:
mouse is ok 

Additional info:
if not change the mac, won't hit this issue
if change the mac, then reboot in guest, won't hit this issue
Comment 2 Qian Guo 2012-12-10 02:46:52 UTC 
About "Additional info" in this bug, 

The words 
"if change the mac, then reboot in guest, won't hit this issue
"
could be recognized as steps
1.after boot the guest, change mac address 
#ifconfig eth0 down && ifconfig eth0 hw ether 54:52:1a:32:b4:01 && ifconfig eth0 up

2.inside guest, do 
guest#reboot

when it boot up again, the mouse works well and won't hit this issue.
Comment 3 Amos Kong 2012-12-11 06:25:07 UTC 
Talked with GuoQian, guest network is fine / keyboard works.
Comment 4 Qian Guo 2012-12-11 09:04:34 UTC 
This bug could not be reproduced with upstream qemu
after 
(qemu)system_reset

mouse works well.

I test this in the same host, using the same cli (as bug Description) and same gues. 
Find difference when "info mice" under qemu :
1.Using qemu-kvm-0.12.1.2-2.342.el6.x86_64
(qemu)info mice
* Mouse #1: vmmouse
  Mouse #0: QEMU PS/2 Mouse

2.Using upstream qemu
(qemu) info mice
  Mouse #0: QEMU PS/2 Mouse
* Mouse #1: vmmouse (absolute)


hope it will be helpful.
Comment 5 Gerd Hoffmann 2012-12-11 10:55:01 UTC 
The mac address change triggering this is really strange.
Does it also happen with another nic (say e1000 instead of virtio)?

Can I get a X-Server logs for both working (after step #2) and non-working (after step #4) case?
Comment 6 Qian Guo 2012-12-12 03:28:54 UTC 
Created attachment 661943 [details]
just boot the rhel6.4 guest in X Winodw

This attachment include 3 logs that are all in the /var/log/
#ls -lh
total 272K
-rw-r--r--. 1 root root 93K Dec 12 18:55 Xorg.0.log
-rw-r--r--. 1 root root 96K Dec 12 18:55 Xorg.0.log.old
-rw-r--r--. 1 root root 80K Dec 12 18:55 Xorg.9.log
Comment 7 Qian Guo 2012-12-12 03:31:04 UTC 
Created attachment 661944 [details]
after system_reset in qemu, catch the logs

Also 3 logs in /var/log/

#ls -lh
total 272K
-rw-r--r--. 1 root root 93K Dec 12 18:59 Xorg.0.log
-rw-r--r--. 1 root root 93K Dec 12 18:59 Xorg.0.log.old
-rw-r--r--. 1 root root 80K Dec 12 18:59 Xorg.9.log
Comment 8 Qian Guo 2012-12-12 03:32:41 UTC 
(In reply to comment #5)
> The mac address change triggering this is really strange.
> Does it also happen with another nic (say e1000 instead of virtio)?

Hi Gerd,

Yes, it happens with other nics, including e1000, rtl8139.

> 
> Can I get a X-Server logs for both working (after step #2) and non-working
> (after step #4) case?

I am confused that why qemu emulate a vmmouse when the cli did not involve it.

Additional info:

When I installed this guest, also installed this:
#rpm -qa \*vmmouse\*
xorg-x11-drv-vmmouse-12.9.0-10.el6.x86_64
Comment 9 Gerd Hoffmann 2012-12-12 08:30:54 UTC 
vmmouse emulation can't be turned off.

And the X-Server logs confirm that in the non-working case the guest didn't load the vmmouse driver, whereas qemu is still routing the mouse events there, so they never arrive.

Can you run "vmmouse_detect; echo $?" for both working and non-working case please?
Comment 10 Qian Guo 2012-12-12 09:15:36 UTC 
(In reply to comment #9)
> vmmouse emulation can't be turned off.
> 
> And the X-Server logs confirm that in the non-working case the guest didn't
> load the vmmouse driver, whereas qemu is still routing the mouse events
> there, so they never arrive.
> 
> Can you run "vmmouse_detect; echo $?" for both working and non-working case
> please?

OK, the result list below

For working case
# vmmouse_detect ; echo $?
0

For non-working case
# vmmouse_detect ; echo $?
1
Comment 11 Gerd Hoffmann 2012-12-12 10:46:15 UTC 
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=5183067
Comment 12 Qian Guo 2012-12-13 02:39:53 UTC 
According to Comment #11

1.Reproduced this bug with qemu-img-0.12.1.2-2.342.el6.x86_64

steps
  1.1 boot guest cli
#/usr/libexec/qemu-kvm -cpu SandyBridge -m 2G -smp 2,sockets=1,cores=2,threads=1 -M rhel6.4.0 -enable-kvm -name testnic2 -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/test2.raw,if=none,format=raw,werror=stop,rerror=stop,cache=none,media=disk,id=drive-scsi0-disk0 -device virtio-scsi-pci,id=scsi0,addr=0x4 -device scsi-hd,scsi-id=0,lun=0,bus=scsi0.0,drive=drive-scsi0-disk0,id=virtio-disk0,bootindex=1 -nodefaults -nodefconfig -monitor stdio -netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-net-pci,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01  -vnc :10 -vga std

  1.2 after guest bootup, in host
(qemu)info mice
* Mouse #1: vmmouse
  Mouse #0: QEMU PS/2 Mouse

  1.3 in guest, see if the guest load the vmmouse driver
# vmmouse_detect ; echo $?
0
  
  1.4 in guest, change the mac address
#ifconfig eth0 down && ifconfig eth0 hw ether 54:52:1a:32:b4:21 && ifconfig up

  1.5 in qemu do system_reset
(qemu)system_reset

Result :after guest bootup, the mouse could not use and repeat step 1.3, show this  out put
# vmmouse_detect ; echo $?
1

So, base on above testing, this bug is reproduced

2.verify this bug with qemu-kvm-0.12.1.2-2.337.el6.bz884450.1.x86_64

2.1 steps is the same as above

Test result 
After system_reset, the guest bootup, mouse works well, and in qemu
(qemu)info mice
* Mouse #1: vmmouse
  Mouse #0: QEMU PS/2 Mouse

in guest do 
# vmmouse_detect ; echo $?
0

So, this bug is fixed by qemu-kvm-0.12.1.2-2.337.el6.bz884450.1.x86_64
Comment 13 Gerd Hoffmann 2012-12-13 08:25:58 UTC 
> So, this bug is fixed by qemu-kvm-0.12.1.2-2.337.el6.bz884450.1.x86_64

Good.  Patches posted.
Comment 20 Qian Guo 2013-01-05 07:21:45 UTC 
1.Reproduced this bug with qemu-kvm-0.12.1.2-2.335.el6.x86_64

steps
  1.1 boot guest cli
#/usr/libexec/qemu-kvm -cpu Penryn -m 2G -smp 2,sockets=1,cores=2,threads=1 -M rhel6.4.0 -enable-kvm -name testnic2 -rtc base=localtime,clock=host,driftfix=slew -drive file=bz884450u1.qcow2,if=none,format=qcow2,werror=stop,rerror=stop,cache=none,media=disk,id=drive-scsi0-disk0 -device virtio-scsi-pci,id=scsi0,addr=0x4 -device scsi-hd,scsi-id=0,lun=0,bus=scsi0.0,drive=drive-scsi0-disk0,id=virtio-disk0,bootindex=1 -nodefaults -nodefconfig -monitor stdio -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01 -vnc :10 -vga std

  1.2 after guest bootup, in host
(qemu)info mice
* Mouse #1: vmmouse
  Mouse #0: QEMU PS/2 Mouse

  1.3 in guest, see if the guest load the vmmouse driver
# vmmouse_detect ; echo $?
0
  
  1.4 in guest, change the mac address
#ifconfig eth0 down && ifconfig eth0 hw ether 54:52:1a:32:b4:21 && ifconfig up

  1.5 in qemu do system_reset
(qemu)system_reset

Result :after guest bootup, the mouse could not use and repeat step 1.3, show this  out put
# vmmouse_detect ; echo $?
1

So, base on above testing, this bug is reproduced

2.verify this bug with qemu-kvm-0.12.1.2-2.348.el6.x86_64

2.1 steps is the same as above

Test result 
After system_reset, the guest bootup, mouse works well, and in qemu
(qemu)info mice
* Mouse #2: vmmouse
  Mouse #0: QEMU PS/2 Mouse

in guest do 
# vmmouse_detect ; echo $?
0

So, this bug is verified with qemu-kvm-0.12.1.2-2.348.el6.x86_64
Comment 22 errata-xmlrpc 2013-02-21 07:45:19 UTC 
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/RHBA-2013-0527.html