Mouse stops working when connected usb-storage-device

I'm running a guest that has Windows 8 Pro (x64) installed. Every time I pass through a usb storage device from the host to the guest, the mouse stops working in the vnc client. When I remove the usb-device the mouse works again.

The mouse only stops working when I pass through a usb storage device and then make the vlc viewer (client) inactief by clicking on another program on the local computer (where I'm running the vnc viewer (client)). As long as I keep the vnc viewer active, the mouse works without any problems. But as soon as I make the vnc viewer inactief and then active again, the mouse will no longer work. I have to reboot the guest or remove the usb storage device.

I can't find any related problems on the internet, so it may be just me?

I hope someone can help me with this.

Thanks for reporting this bug.

Could you tell us which Ubuntu release you are running?  Was 'vlc viewer' a typo, or is that another program you have running beside the vnc viewer?

If you are starting this VM using libvirt, please attach the xml definition for the VM (virsh dumpxml vm-name).  If using the command line, please show us the full exact command you are using.

Also please show the result of 'sudo lsusb' after plugging in the usb storage but before passing it through to the guest, then again after passing it through.

Finally please show exactly how you are passing through the usb device.

If these don't show anything obvious then I'll try to reproduce.

(marking low priority because there is a workaround - unplugging the usb device)

Actually I had three more questions - 

1. If you exit the vnc viewer and restart it, does the mouse work again?

2. What window manager are you using?

3. Which vnc client are you using?  (What command do you use, and what does 'dpkg -l | grep vnc' show?)

Thanks for the reply!

First of all, vlc was a type. Should have been vnc. If I restart the vnc viewer (client) the mouse still does not work. Even connecting from another computer does not seem to fix the problem.

I'm using Virtual Machine Manager (virt-manager) to assign the usb-device to the guest. I do this by clicing on 'Add device', select USB Host device, then select the usb external hard drive and click 'Apply'. After this action, the hard drive is visible and working on the guest.

I'm using Ubuntu 14.04 LTS with libvirt 1.2.2. Here is my xml-file before and after adding the usb device:



A little more information I discovered:

I told before that the mouse only stops working when making the vnc viewer (client) inactive. This is not true after some more testing. It just happens when adding the usb external storage device to the guest and wait for like 10 seconds. Then the mouse stops working (clicking, moving...). The keyboard still works without any problems. I'm sorry for the wrong information above.

I' very sorry, but I forgot to add the xml files before clicking 'Post Comment' and it seems that I cannot edit my posts (only the poststart).

Here they are:

[BEFORE ADDING DEVICE]

<domain type='kvm'>
  <name>vm01</name>
  <uuid>4ffa27ba-cb99-6375-23ab-92913e18cf75</uuid>
  <description>THUIS-SERVER</description>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu>
    <topology sockets='1' cores='4' threads='1'/>
  </cpu>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/vm01.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:8f:1b:a4'/>
      <source bridge='br0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='apparmor' relabel='yes'/>
</domain>


[AFTER ADDING DEVICE]

<domain type='kvm'>
  <name>vm01</name>
  <uuid>4ffa27ba-cb99-6375-23ab-92913e18cf75</uuid>
  <description>THUIS-SERVER</description>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu>
    <topology sockets='1' cores='4' threads='1'/>
  </cpu>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/vm01.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:8f:1b:a4'/>
      <source bridge='br0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x03f0'/>
        <product id='0x070c'/>
      </source>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='apparmor' relabel='yes'/>
</domain>


[LSUSB BEFORE]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

[LSUSB AFTER]

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 03f0:070c Hewlett-Packard 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I hope you have enough information with this. Thanks again for the reply!

Some more information that I think is relevant:

The motherboard that the server uses is an IPIBL-LA (http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01247779&tmp_task=prodinfoCategory&cc=be&dlc=nl&lc=nl&product=3627668#N84) and according to the specifications it has all USB 2.0 ports. However in Ubuntu when using 'lsusb' I only see 2 EHCI (USB 2.0) controllers/ports. All the rest are 1.1.

Is this normal or is this a bug? I couldn't find any more information on the internet for this bug/problem. It seems that Ubuntu does not recognize all of the USB 2.0 ports and sees them as 1.1 insteid? I'm also receiving this error on host boot (when booting the server): kvm [1698]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff. After some research I found that some say this is not an error. But it is related to Qemu. Could this also be something to do with my mouse problem?

Again, many thanks for reading!

the 

kvm [1698]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff

should be innocuous and unrelated.  The host motherboard info may
be relevant, but shouldn't be.  Libvirt should be able to pass in
just the right device.

The xml descriptions look correct.  The lspci outputs seem backward,
as device

Bus 001 Device 004: ID 03f0:070c Hewlett-Packard 

shows up in the after, but not before, outputs.

I'll try to reproduce after I manage to set up a remote windows
vm, using a usb flash drive.

Can you confirm whether the hard drive appears to become available
in the windows vm?


Thanks for the response!

Yes, the hard drive does become available in the Windows vm. I can use it as I would normally do in a non-virtual environment. I have not yet tried any other Windows version. I'm running Windows 8.1 x64.

Any news on this yet? I do not want to hurry you but it has been a bit quiet.

I am now installing Windows 7 SP1 x64 to see if it suffers from the same bug/problem. I'll report back when I have more information!

I can confirm that this bug/problem does not seem to exist in Windows 7 SP1 x64! I could use this version of Windows w/ my external hard drives, but it's strange that this exact same set-up does not work on Windows 8 (causing the vnc mouse to freeze). This could and should be a Windows 8 driver problem with the Qemu mouse-driver. I hope this can be reproduced and fixed a.s.a.p.!

If you need any more information or help, just ask me and I'll be free to help you reproduce this bug.

I finally found a fix for this bug/problem! It is in fact a bug, but I don't know wether it is a Windows bug or a Qemu/VNC-bug. After connecting a massive storage device to the Windows 8.1 guest, the mouse stops working because it goes into a sleep-state.

This bug can be fixed by going to WIN + X, Control Panel, Devices and Printers. There you can see the QEMU USB Tablet which is a tablet/mouse device used for the VNC-mouse to work on the guest. Right click it and select Properties. Next click on the tab Hardware. Normally you should see two devices (based on what hardware you assigned to the guest), HID-compliant mouse and USB Input Device.

Now select the USB Input Device and click Properties at the bottom. This will open a new window with the device's properties. Next click on Change settings (you'll need Admin.-powers for this) and go to the Power Management tab on the newly opened window. There you should see an option ticked with the following explanation: Allow the computer to turn off this device to save power.

Unchecking that option and pressing OK solves the problem. This whole route can be done with keyboard-only (as the keyboard still works). Press ENTER to open things, use TAB to move to different menus and press SPACE to simulate a single mouse-click (for unchecking the checkbox).

I hope this helps a lot of people who are suffering from the same issue. I still can't find any related topics of people having the same issues as I did, but it is a bug and should be fixed. I have no idea if it is Windows or Qemu related and I hope that the Qemu-team can further inspect this.

Thanks for all the help!

Hi,

Are you running 12.04, or 14.04?  If 12.04, would it be possible to test 14.04 to see if it has the same issue?  If 14.04, could you try with the following ppa:  https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream    to see if the very latest upstream qemu still has the same behavior?

I'm using 14.04. I could give it a try. Is it easy to revert to the older version of Qemu once upgraded to the upstream one?

Using the latest upstream version the bug still exists. I have to disable the option that Windows can put the USB Input Device to sleep in order to make the mouse move again.

Any news on this?

Sorry, no.  So to summarize for anyone on the qemu-devel mailing list who might have ideas, Rubin found that disabling power management for the mouse device in windows fixes the issue.  With power management enabled, plugging in a usb storage device and passing it through to the guest stops the mouse from working in the windows guest.

Ok, thanks for the info! By Rubin, do you mean Ruben (a.k.a. me)? :D

> Ok, thanks for the info! By Rubin, do you mean Ruben (a.k.a. me)? :D

D'oh - yes, apologies.


Magic! I'd been trying to figure out how to prevent my mouse from stopping at apparently random points... Works like magic!

Glad to hear you solved they issue by reading this bug report, Maarten! As you can see the bug has been updated with the confirmed-status on October 21st of 2015 and I hope they can fix this a.s.a.p. I don't have a Windows-guest anymore, but even for all the other Qemu-users out there that do, I'd like this bug fixed.

@Stefan or Chris, or any other developer: is there any news/updates about this issue?

Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?

It's been a very very long time since I've last ran a Windows virtual machine on Ubuntu, so I can't really tell. I do remember I never got it "fixed", but did find a fix for it by disabling the Windows power plan option "Allow Windows to put this device to sleep". Over the years I did get some thankful comments on the StackOverflow threat where I posted this exact issue with the workaround (fix), which can be viewed here: https://unix.stackexchange.com/questions/131942/qemu-2-0-windows-guest-mouse-stops-working-vnc-when-using-usb-passthrough

[Expired for QEMU because there has been no activity for 60 days.]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

I have had this issue happen multiple times on multiple versions of kvm with both ubuntu and cantos.  I just the other day tried installing win8.1 again for testing and ran across ruban's post.  this happens in win10 as well and I think I had seen it in win7.

I reinstalled another win8 vm from a usb instead of an iso later that day and realized that the mouse was working normally which surprised me.   I then manually installed the virtio nic driver.  the system still worked normally.  I then installed the baloon driver and that make the mouse stop working untill i pulled the flash drive.  after changing the power settings the mouse would again start working with the flash drive.  

I have always used virt manager for connecting to the servers and spice for the display 

@Kendrick could you please tell us which version of Ubuntu and qemu you are using?


This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/102


I have used rel 7.x 8.x ubuntu 18.04 and see this happening in all of them the original user had it only in ubuntu.