Bug 1318219

Hi fjin,

Could you reply comment2?

Best Regards,
Junyi

Gerd, can you take a look?

can you switch back to the virtio mouse via "mouse_set" monitor command?

(In reply to Gerd Hoffmann from comment #6)
> can you switch back to the virtio mouse via "mouse_set" monitor command?

Hi, Gerd
   I retest use command, find can't switch back to the virtio mouse via "mouse_set".
 
and no matter do or not do migration, just can switch from virtio to ps/2, can't switch ps/2 to virtio mouse.

Can you provide the libvirt xml please; I couldn't reproduce it using a simple test here.

Dave

Also, I think you might have an error in your original report - you did the 'query-mice' command on the rhel7.2 domain not the fedora23 domain you describe the rest of the problems with;  please include the output of query-mice on the same domain as the bug.

I test this BZ again, it can be reproduced on build qemu-kvm-rhev-2.5.0-2.el7.x86_64 (though the result is slightly different), and CAN NOT be reproduced on build qemu-kvm-rhev-2.6.0-9.el7.x86_64. Steps are as below:

Test on build rhev-2.5.0-2.el7.x86_64:
1)# virsh start rhel7

2)# virsh qemu-monitor-command rhel7 --pretty '{"execute": "query-mice"}'
{
  "return": [
    {
      "index": 2,
      "name": "QEMU PS/2 Mouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 3,
      "name": "QEMU Virtio Mouse",
      "current": true,
      "absolute": false
    }
  ],
  "id": "libvirt-13"
}


3)# virsh managedsave rhel7
# virsh start rhel7


4)# virsh qemu-monitor-command rhel7 --pretty '{"execute": "query-mice"}'
{
  "return": [
    {
      "index": 3,
      "name": "QEMU Virtio Mouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 2,
      "name": "QEMU PS/2 Mouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 4,
      "name": "vmmouse",
      "current": true, ===> here is the current mouse
      "absolute": false
    }
  ],
  "id": "libvirt-13"
}


Test on build rhev-2.6.0-9.el7.x86_64:
1)# virsh start rhel7

2)# virsh qemu-monitor-command rhel7 --pretty '{"execute": "query-mice"}'
{
  "return": [
    {
      "index": 2,
      "name": "QEMU PS/2 Mouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 3,
      "name": "QEMU Virtio Mouse",
      "current": true,
      "absolute": false
    }
  ],
  "id": "libvirt-13"
}


3)# virsh managedsave rhel7
# virsh start rhel7

4)# virsh qemu-monitor-command rhel7 --pretty '{"execute": "query-mice"}'
{
  "return": [
    {
      "index": 2,
      "name": "QEMU PS/2 Mouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 4,
      "name": "vmmouse",
      "current": false,
      "absolute": false
    },
    {
      "index": 3,
      "name": "QEMU Virtio Mouse",
      "current": true, ===> here is the current mouse
      "absolute": false
    }
  ],
  "id": "libvirt-13"
}

Created attachment 1172558 [details]
domain xml

Thanks! Yes, I can recreate this behaviour on 2.5.0 *and* 2.3.0 from 7.2 but not the current 2.6.0;  I'm going to keep on looking at it, because I want to understand whether it was really fixed or we just got lucky.

Some notes on pulling different versions apart:

Thanks;  there are some interesting differences using a 7.2 guest and there's definitely
something weird happening with migration but it does seem to be better in the 2.6.0/7.3 build;
the following are all with a 7.2 guest:

2.6.0-9
(at X login) we have:
[root@virtlab413 ~]# virsh qemu-monitor-command input-rhel7 --hmp --cmd "info mice"
  Mouse #2: QEMU PS/2 Mouse
* Mouse #3: QEMU Virtio Mouse

but then after a managedsave:
[root@virtlab413 ~]# virsh qemu-monitor-command input-rhel7 --hmp --cmd "info mice"
  Mouse #2: QEMU PS/2 Mouse
  Mouse #4: vmmouse             <<<<<<<
* Mouse #3: QEMU Virtio Mouse

so after migration on 2.6.0, vmmouse has woken up even though there is no guest change,
but at least it's not the default.

Without X running, this doesn't happen; I guess that suggests that whatever logic
the vmmouse code decides to use to register post_load is broken.

Both 2.5.0 and 2.3.0 (rhel packages) have different behaviour:

 X
  Mouse #2: QEMU PS/2 Mouse
* Mouse #3: QEMU Virtio Mouse

Resume:
[root@virtlab413 x86_64]# virsh qemu-monitor-command input-rhel7 --hmp --cmd "info mice"
  Mouse #3: QEMU Virtio Mouse
  Mouse #2: QEMU PS/2 Mouse
* Mouse #5: vmmouse (absolute)  <<<! Note gained this and now default?!

So that's probably bad; I wonder if that can explain some other weird behaviours with mice
breaking after migration.

Without X:
     Mouse #2: QEMU PS/2 Mouse
   * Mouse #3: QEMU Virtio Mouse

 after restore:
     Mouse #3: QEMU Virtio Mouse
   * Mouse #2: QEMU PS/2 Mouse     <!!!! Note swap!!!

So again we have a change in what is active.

So I think we have 1 problem and 2 ex-problems:
   a) (all under X) vmmouse appears post migrate even if it wasn't previously 
   b) (2.5.0 and earlier under X) vmmouse appears and is made current
   c) (2.5.0 and earlier no X) PS/2 gets selected as current mouse instead of virtio

Dave

(c) is the easy case to explain; it's fixed by 2d738374 which adds the live migration support to virtio-input.  So now we know why it works in 2.6 but not 2.5.

Still need to dig to see the logic vmmouse uses to see when it appears after migrate (a & possibly b).
Also there's another case:

  d) (all no X) mouse_set to the PS/2 to select it explicitly; migrate and this is forgotten and we're back on virtio.  Probably less important.

Dave

Some more debug,   (d) and (a) are both real bugs, but since vmmouse never seems to get selected in any useful state where usb/virtio are also present I don't think (a) matters.
I also don't think (d) matters because as far as I can tell libvirt doesn't use mouse-set so probably nothing uses it, especially downstream.

Some more notes:
  a) I tried vmmouse+USB tablet - usb tablet always gets selected (it's setup to always be selected when it's read); so at least it's consistent.
  b) I tried virtio mouse+USB tablet - virtio always seems to win; I'm not really sure why, but it stays that way across migration.

So I think we're OK for all real uses; it might be preferable to migrate the current selected device though to cover (d) and to do something so that vmmouse doesn't pop up after migration.

So closing as current release; it's fixed in 2.6.0 by 2d738374.