[lucid kvm-qemu]High cpu usage when moving mouse

I removed 1:12.6.5-4ubuntu1 and installed 1:12.6.5-2ubuntu4 from launchpad, and the system was responsive after reboot. Then, I installed 1:12.6.5-4ubuntu1 back and the system had poor response again after reboot.

What I don't understand though is that prior to today I had 1:12.6.5-2ubuntu4, but I had responsiveness issues then too.
I could try a fresh install tomorrow and see if I get the same results.

Could you please paste your kvm command line when you start your VM?

I have actually been having this same issue for a while I can confirm that removing xserver-xorg-input-vmmouse does indeed make the system usable again.

/usr/bin/kvm -m 512 -smp 2 -hda /mnt/Storage/kvms/lucid-test.img
Is what I use for my command

After thinking about this some more, I am not convienced that it actually is xserver-xorg-input-vmmouse. I also have a lucid JeOS guest and the framebuffer moves painfully slow when text is scrolling if I connect to it with virt-viewer, however if I ssh into it it runs at normal speed. I dont have xorg let alone xserver-xorg-input-vmmouse, granted this could be two different bugs. Any ideas on how to find out?

kvm /storage/greg/vm/Lucid_64.qcow2 -m 1024

I get the same result booting from the live cds:
kvm -m 1024 -cdrom ubuntu-10.04-beta1-desktop-amd64.iso
kvm -m 1024 -cdrom lucid-desktop-amd64.iso

lucid-desktop-amd64.iso is the daily-cd

md5sums:
d88edd4c3640e2c90dd2bce16dbe86ae lucid-desktop-amd64.iso
7341b637218cf9a9b2334293c3df7e94 ubuntu-10.04-beta1-desktop-amd64.iso

Host info:
     *-cpu
          product: AMD Athlon(tm) Dual Core Processor 4850e
          vendor: Advanced Micro Devices [AMD]
          physical id: 1
          bus info: cpu@0
          size: 2500MHz
          capacity: 2500MHz
          width: 64 bits
          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp x86-64 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch cpufreq

uname -a
Linux Shredder 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:27 UTC 2010 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic

The vmmouse driver is used to have a "transparent" mouse between the virtual machine and the desktop. ie: no need to press ctrl-alt to release the mouse.

vmmouse worked automatically in jaunty, but was broken in Karmic. The patch in 1:12.6.5-2ubuntu3 makes it get detected in Lucid again, and enabled automatically.

Yes, the vmmouse driver is more CPU intensive than the regular mouse emulation. Moving the mouse around rapidly in circles in a Lucid VM on my machine results in 20-30% cpu usage. Under normal mouse usage, it doesn't use that much.

How much CPU usage are you experiencing?

If I attempt to move the mouse from one end of the screen to the other, it pauses half way in between and cpu usage goes to 80% - 100% (measured in htop)
The lack of responsiveness makes it unusable.
I will try jaunty and see...I don't recall having this issue with it.

Removing vmmouse is a solution for me, but I don't think this should be ignored.

Just moving the mouse from one end to the other should definitely not cause 100% cpu usage.

Unfortunately, I cannot reproduce this.

vmmouse_detect; echo $? produces 1, should that mean something?

With the fixed vmmouse package, vmmouse_detect should return 0. If it returns 1, xorg should not be using the vmmouse driver.

If I am using kvm-qemu and not VMware, should the vmmouse driver be active?
I will double check with the vmmouse_detect thing, but xorg is logging:
(II) VMWARE(0): VMMOUSE DEVICE_INIT
(II) VMWARE(0): VMMOUSE DEVICE_ON
(II) VMWARE(0): vmmouse enabled
...
(II) VMWARE(0): vmmouse enable absolute mode
(II) VMWARE(0): vmmouse enable absolute mode

My version of kvm-qemu on the host is:
QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0)

Yes, vmmouse is the driver that kvm supports to enable the mouse cursor automatically entering and leaving the guests window.

This bug affects me as well; exact same symptoms as described above, with a fresh 10.04 x86_64 Beta 2 install & synaptic update on the Host machine.

As I said before its not just vmmouse if I use virt-viewer to connect to a vm that doesn't even have xorg installed and do a "ls -R /" I get 100% CPU usage and the text scrolls at a snails pace. However if I ssh into the vm and issue the same command it uses almost no CPU and scrolls very fast like it would if I issued it from a terminal on the host.

Unlike Ezra Reeves, I only have the mouse issue. When I move my mouse, the "xorg" process of the VM goes to 100% (I can get more CPU usage if I enable many processors), and so does the KVM process. It happens:
- with KVM native display or VNC
- using KVM directly or through libvirt
The rest seems to be fine. VirtualBox doesn't have such an issue.

My configuration:
- 64bits
- physical system: Kubuntu 10.04
- virtualized system: Ubuntu or Kubuntu 10.04, 32bits or 64bits

No problem when virtualizing 9.10 on the same machine.

I am attempting to install Lubuntu, but I am getting the same behavior with the live cd (there is no alt install yet).
The problem here is that clicking install causes the screen to flicker and the installation dialog keeps moving down...I suspect this to be caused by this bug since I have experienced similar issues when running ubuntu with kvm and vmmouse active.

Just a precision (may not be obvious to everyone): "xserver-xorg-input-vmmouse" has to be uninstalled on the virtualized system, not in the hosting system. Which is not very convenient when running a live CD, because the user has to install it, then restart the X server (each time he runs the liveCD).

Setting the live cd to run in safe mode works around the issue.

I'm seeing almost the same behavior in an 8.04.4 guest on a 10.04 host.

The mouse pointer movement in the guest was ABYSMALLY slow until I edited /etc/X11/xorg.conf to use 'mouse' instead of 'vmmouse'. After doing that and restarting X, mouse performance inside the guest matched that of the host. I lost the ability to seamlessly transition between the virt-manager window and the host, but this is a minor convenience. Having the mouse pointer move in conjunction with my physical mouse is a necessity.

I did not notice the high CPU usage that others are reporting in this bug.

The high cpu usage was on the host only when the mouse on the guest was being moved rapidly.

I have noticed the same issue with mouse movements causing high cpu usage (100% on two occasions_) locking out the kvm

this is an important issue to resolve as it can quite easily render your KVM useless .... I actually completely lose ability to ssh in to virtual machine at this point.

using Ubuntu 10.04 64 bit host, and Ubuntu 64 bit guest.

@Julian: Does removing xserver-xorg-input-vmmouse from the client fix the issue?
Also, what cpu do you have? I am wondering if this might be unique to AMD processors.

I have tried this and removing xserver-xorg-input-vmmouse did in fact make the system usable again on maverick.

This is happening to me with Lucid 64 using KVM on Fedora. The mouse moving normally causes Lucid to grind to a halt and the mouse becomes barely usable. If I stop moving it for a minute it works again but basically the system becomes unusable (I had to reboot between running vmmouse_detect and viewing Xorg.0.log).
 I run qemu like this:
 qemu-kvm -M pc -m 2048 -hda images/lucid64a -net nic -net user -usb

vmmouse_detect returns 1, I'm using an AMD 620 CPU

Here's the mouse info from Xorg's log:

(II) config/udev: Adding input device ImExPS/2 Generic Explorer Mouse (/dev/input/event3)
(**) ImExPS/2 Generic Explorer Mouse: Applying InputClass "evdev pointer catchall"
(**) ImExPS/2 Generic Explorer Mouse: Applying InputClass "vmmouse catchall"
(II) LoadModule: "vmmouse"
(II) Loading /usr/lib/xorg/modules/input/vmmouse_drv.so
(II) Module vmmouse: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 12.6.5
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 7.0
(II) VMWARE(0): VMMOUSE module was loaded
(II) VMWARE(0): vmmouse is available
(**) ImExPS/2 Generic Explorer Mouse: always reports core events
(**) Option "Device" "/dev/input/event3"
(**) ImExPS/2 Generic Explorer Mouse: ZAxisMapping: buttons 4 and 5
(II) XINPUT: Adding extended input device "ImExPS/2 Generic Explorer Mouse" (type: MOUSE)
(**) ImExPS/2 Generic Explorer Mouse: (accel) keeping acceleration scheme 1
(**) ImExPS/2 Generic Explorer Mouse: (accel) acceleration profile 0
(**) ImExPS/2 Generic Explorer Mouse: (accel) acceleration factor: 2.000
(**) ImExPS/2 Generic Explorer Mouse: (accel) acceleration threshold: 4
(II) VMWARE(0): VMMOUSE DEVICE_INIT
(II) VMWARE(0): VMMOUSE DEVICE_ON
(II) VMWARE(0): vmmouse enabled
(II) config/udev: Adding input device ImExPS/2 Generic Explorer Mouse (/dev/input/mouse1)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/event1)
(**) Macintosh mouse button emulation: Applying InputClass "evdev pointer catchall"
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event1"
(II) Macintosh mouse button emulation: Found 3 mouse buttons
(II) Macintosh mouse button emulation: Found relative axes
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Configuring as mouse
(**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
(**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) Macintosh mouse button emulation: initialized for relative axes.
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/mouse0)
(II) No input driver/identifier specified (ignoring)
(II) VMWARE(0): vmmouse enable absolute mode

Oh yeah other versions work fine, same qemu command , 8.04 , 9.10

Running kvm on AMD 64 bit, this problem occurs for 64 guests regardless of the guest mouse driver (mouse or vmmouse). It does not affect 32bit guests.

-jh

@jh: You might be experiencing a different bug, since both 32bit and 64bit guests are unusable with vmmouse installed.

-vmmouse is gone since 16.10, closing