Created attachment 559842 [details]
guest log file

qemu command line is suspicious:
1) -vga std
   If you run with spice, why isn't it -vga qxl?
2) -device usb-tablet
   Shouldn't be used with spice.

(In reply to comment #3)
> qemu command line is suspicious:
> 1) -vga std
>    If you run with spice, why isn't it -vga qxl?
> 2) -device usb-tablet
>    Shouldn't be used with spice.

With -vga qxl and without usb-tablet, the problem still exists (already install qxl-win on guest)

/usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name mig -uuid cb3c3fbe-2e33-a9de-072d-dad46d2ecb60 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/mig.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/mnt/win7-x86_64,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=22,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:a2:19:5e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -spice port=5900,addr=0.0.0.0,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -incoming tcp:0.0.0.0:49164 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

Why do you believe this to be a libvirt BZ?  I'm not saying it isn't, I'm just asking whether you have any evidence to suggest that it doesn't appear with qemu-kvm alone?

(In reply to comment #5)
> Why do you believe this to be a libvirt BZ?  I'm not saying it isn't, I'm just
> asking whether you have any evidence to suggest that it doesn't appear with
> qemu-kvm alone?

I think it is not libvirt problem, but I am not sure whether it is qemu-kvm bug or spice-qxl-driver-win bug

(In reply to comment #6)
> (In reply to comment #5)
> > Why do you believe this to be a libvirt BZ?  I'm not saying it isn't, I'm just
> > asking whether you have any evidence to suggest that it doesn't appear with
> > qemu-kvm alone?
> 
> I think it is not libvirt problem, but I am not sure whether it is qemu-kvm bug
> or spice-qxl-driver-win bug

In bug 731100, comment 22 & comment 23, the kvm QE did the related test. And also, i talked to him to confirm that he didn't get the mouse problem.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Why do you believe this to be a libvirt BZ?  I'm not saying it isn't, I'm just
> > > asking whether you have any evidence to suggest that it doesn't appear with
> > > qemu-kvm alone?
> > 
> > I think it is not libvirt problem, but I am not sure whether it is qemu-kvm bug
> > or spice-qxl-driver-win bug
> 
> In bug 731100, comment 22 & comment 23, the kvm QE did the related test. And
> also, i talked to him to confirm that he didn't get the mouse problem.
Just confirm with chayang again, the qemu command he used in bug 731100, comment 22 didn't add the qemu vmc channel, so he didn't hit this problem, after add the channel, he can also reproduce this bug. 
So this's not a libvirt bug.

Yonit, are you saying that libvirt is generating an incorrect qemu command line?

(In reply to comment #9)
> Yonit, are you saying that libvirt is generating an incorrect qemu command
> line?

I'm not sure what yanbing du did to generate the command I saw in the attachment in comment #1. In that specific case, the command line is not appropriate for testing spice.
According to comment #8 this is not a libvirt bug.
However, I never saw this bug when executing migration via rhevm.
I think this bug can be moved, maybe to qemu-kvm. But first it should be reproduced on rhevm. In addition, when reproducing it with directly using qemu, I would like to see the exact command line.

Yonit.

Michal, if you specify spice graphics in the xml do you get -vga qxl on the qemu commandline?

Yes, I do:

2012-02-14 12:57:15.563+0000: 26243: debug : virCommandRunAsync:2178 : About to run LC_ALL=C PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin HOME=/root USER=root QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -S -M pc-0.15 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win7 -uuid 288d5ff7-9808-29af-e4ce-4f74336387cc -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/mnt/masina_nfs/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:60:ed:14,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=0.0.0.0,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

unless I specify default vga card in virt-manager;

I've managed to run qemu by hand, that means without libvirt, and I got the same result as the reporter. Therefore I think it is not a libvirt bug. Btw: there was no time difference between the hosts, they were completely synchronized.

Given the above, I'm moving the BZ to qemu for further investigation; if there's anything libvirt can do here, please let me know.

Hi Yanbing Du,
Please perform the following verification and provide feedback. We'll continue based on your answers.
1. Is vdservice (RHEV Spice Agent) running before the migration? is it client mouse mode, where cursor is not captured in client window?
2. Stop vdservice. Does it switch to server mouse mode (cursor captured in client)?
3. Run the same migration scenario you ran before. Do you have mouse (still server mode)?
4. Start vdservice. Does it start correctly? Do you have mouse (should be client mode, no capture)?

(In reply to comment #14)
> Hi Yanbing Du,
> Please perform the following verification and provide feedback. We'll continue
> based on your answers.
> 1. Is vdservice (RHEV Spice Agent) running before the migration? is it client
> mouse mode, where cursor is not captured in client window?
>
_Without_ vdservice running in guest, after migration, the cursor won't be captured.
_With_ vdservice running in guest, cursor changes to not captured in client guests.

> 2. Stop vdservice. Does it switch to server mouse mode (cursor captured in
> client)?
>
Yes, indeed.

> 3. Run the same migration scenario you ran before. Do you have mouse (still
> server mode)?
>
Yes, indeed.

> 4. Start vdservice. Does it start correctly? Do you have mouse (should be
> client mode, no capture)?
>
Yes, it starts correctly and curse is not captured in client window.



I got the above behavior with qemu-kvm directly with qemu-kvm-0.12.1.2-2.229.el6.x86_64. 
I think this is not a bug if the vdservice is the switch to capture curse.

vdservice starts: curse won't be captured
vdservice stops: curse will be captured

CLI:
/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1 -name test -uuid 3d4aff0c-f8f0-4341-872d-4aabca9d5293 -rtc base=localtime,clock=host,driftfix=slew -boot menu=on -drive file=/mnt/win7-64.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-virtio-0-0,id=virt0-0-0,bus=ide.0,unit=0 -netdev tap,id=net -device virtio-net-pci,netdev=net,id=net0,mac=64:31:50:23:49:1f -usb -spice port=9000,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -monitor stdio -balloon none -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -incoming tcp:0:7000

(In reply to comment #15)
> (In reply to comment #14)
> > Hi Yanbing Du,
> > Please perform the following verification and provide feedback. We'll continue
> > based on your answers.
> > 1. Is vdservice (RHEV Spice Agent) running before the migration? is it client
> > mouse mode, where cursor is not captured in client window?
> >
> _Without_ vdservice running in guest, after migration, the cursor won't be
> captured.
> 
I mean without vdservice installed in guest

> _With_ vdservice running in guest, cursor changes to not captured in client
> guests.
>

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > Hi Yanbing Du,
> > > Please perform the following verification and provide feedback. We'll continue
> > > based on your answers.
> > > 1. Is vdservice (RHEV Spice Agent) running before the migration? is it client
> > > mouse mode, where cursor is not captured in client window?
> > >
> > _Without_ vdservice running in guest, after migration, the cursor won't be
> > captured.
> > 
> I mean without vdservice installed in guest

Not running and not installed are the same for this case. What you say is that in this mode mouse will continue to work ok after migration?

> 
> > _With_ vdservice running in guest, cursor changes to not captured in client
> > guests.
> >

So in this mode mouse will loose after migration?
Does vdservice (which is running before) stop after migration? or stops functioning?
Does vdservice restart (after mouse is lost) fix the problem?

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > Hi Yanbing Du,
> > > > Please perform the following verification and provide feedback. We'll continue
> > > > based on your answers.
> > > > 1. Is vdservice (RHEV Spice Agent) running before the migration? is it client
> > > > mouse mode, where cursor is not captured in client window?
> > > >
> > > _Without_ vdservice running in guest, after migration, the cursor won't be
> > > captured.
> > > 
> > I mean without vdservice installed in guest
> 
> Not running and not installed are the same for this case. What you say is that
> in this mode mouse will continue to work ok after migration?
> 
Yes, not running and not installed get the same mouse behavior before/after migration.(before: mouse gets captured; after: not captured).

Without vdservice running, mouse could be captured. Once starts vdservice, mouse loses. Mouse will be re-captured if stop vdservice.

> > 
> > > _With_ vdservice running in guest, cursor changes to not captured in client
> > > guests.
> > >
> 
> So in this mode mouse will loose after migration?
> Does vdservice (which is running before) stop after migration? or stops
> functioning?
> Does vdservice restart (after mouse is lost) fix the problem?
>
Starts vdservice before migration(then mouse not captured as described in above), vdservice is still running after migration, and restart vdservice doesn't help to capture the mouse.

A brief summary:
According to my testing:
This bug is nothing to do with migration, once start vdservice,Spice Client mouse loss.

retested with older qemu-kvm, like qemu-kvm-0.12.1.2-2.192.el6.x86_64. After starting vdservice, spice client mouse _won't_ lose.

(In reply to comment #19)
> A brief summary:
> According to my testing:
> This bug is nothing to do with migration, once start vdservice,Spice Client
> mouse loss.

I will try to argue that, I can see two bugs messed up together here:
1. After the migration client mouse mode does not work (original report of this bug).
Once an user migrate a guest with client mouse mode (vdservice running) hosted on qemu >= 218 (not sure about exact version it was introduced) client mouse mode is not working properly because pointer is stuck in 0,0 coordinates.
This happens in server mouse mode as well (without vdservice running), after migration cursor jumps to 0,0 coordinates, even though It's not stuck there.

2. Client mouse mode does not work bug #796203 at all.
Once user tries to use guest hosted on qemu >= 228 with client mouse mode (vdservice running) He/she is not possible to make a click into guest.

Both of the bugs occur on latest qemu I have -232 from nightly repo.

(In reply to comment #21)
> (In reply to comment #19)
> > A brief summary:
> > According to my testing:
> > This bug is nothing to do with migration, once start vdservice,Spice Client
> > mouse loss.
> 
> I will try to argue that, I can see two bugs messed up together here:
> 1. After the migration client mouse mode does not work (original report of this
> bug).
> Once an user migrate a guest with client mouse mode (vdservice running) hosted
> on qemu >= 218 (not sure about exact version it was introduced) client mouse
> mode is not working properly because pointer is stuck in 0,0 coordinates.
> This happens in server mouse mode as well (without vdservice running), after
> migration cursor jumps to 0,0 coordinates, even though It's not stuck there.
> 
Hi Marian,
- On qemu < 218 with the same spice versions there is no such problem?
- Do you run qemu directly or via libvirt/rhevm?
- Can you please add the qemu command?

Thanks,
Yonit.

> 2. Client mouse mode does not work bug #796203 at all.
> Once user tries to use guest hosted on qemu >= 228 with client mouse mode
> (vdservice running) He/she is not possible to make a click into guest.
> 
> Both of the bugs occur on latest qemu I have -232 from nightly repo.

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #19)
> > > A brief summary:
> > > According to my testing:
> > > This bug is nothing to do with migration, once start vdservice,Spice Client
> > > mouse loss.
> > 
> > I will try to argue that, I can see two bugs messed up together here:
> > 1. After the migration client mouse mode does not work (original report of this
> > bug).
> > Once an user migrate a guest with client mouse mode (vdservice running) hosted
> > on qemu >= 218 (not sure about exact version it was introduced) client mouse
> > mode is not working properly because pointer is stuck in 0,0 coordinates.
> > This happens in server mouse mode as well (without vdservice running), after
> > migration cursor jumps to 0,0 coordinates, even though It's not stuck there.
> > 
> Hi Marian,
> - On qemu < 218 with the same spice versions there is no such problem?
I do not know, many previous versions of qemu-kvm are already dumped in brew, the newest available under 218 is 209, and It works over there.
> - Do you run qemu directly or via libvirt/rhevm?
Directly
> - Can you please add the qemu command?
udo /usr/libexec/qemu-kvm -m 1024 -smp 2 -vga qxl -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0  -spice port=3010,disable-ticketing /dev/mapper/rootvg-Windows7_test -monitor stdio
> 
> Thanks,
> Yonit.
> 
> > 2. Client mouse mode does not work bug #796203 at all.
> > Once user tries to use guest hosted on qemu >= 228 with client mouse mode
> > (vdservice running) He/she is not possible to make a click into guest.
> > 
> > Both of the bugs occur on latest qemu I have -232 from nightly repo.

*** Bug 798143 has been marked as a duplicate of this bug. ***

Here are some updates:

-- with qemu-kvm-0.12.1.2-2.234.el6.x86_64
1. launch a win-7 guest directly with qemu-kvm without vdservice installed in guest
2. live migrate to a remote host

Result:
Before migration, mouse works fine.
After migration, mouse not work, just disappears. Mouse appears once vdservice gets installed but couldn't click. Mouse could click anywhere once start vdservice via 'net start vdservice'

-- with qemu-kvm-0.12.1.2-2.234.el6.x86_64, libvirt-0.9.10-2.el6.x86_64
Confirmed with reporter that he didn't install vdservice in guest.
Repeat the steps mentioned by reporter without vdservice installed in guest.

Result:
Exactly the same result as I mentioned above. That is:
Before migration, mouse works fine.
After migration, mouse not work, just disappears. Mouse appears once vdservice gets installed but couldn't click. Mouse could click anywhere once start vdservice via 'net start vdservice'

CLI I use:
/usr/libexec/qemu-kvm -M rhel6.3.0 -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1 -name test -uuid 3d4aff0c-f8f0-4341-872d-4aabca9d5293 -rtc base=localtime,clock=host,driftfix=slew -boot menu=on -drive file=/mnt/windows7-64.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-virtio-0-0,id=virt0-0-0 -netdev tap,id=net -device virtio-net-pci,netdev=net,id=net0,mac=64:31:50:23:49:1f -usb -spice port=9000,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -balloon none -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -monitor stdio



Thanks for yanbing du's help and confirmation on libvirt side.

(In reply to comment #25)
> Here are some updates:
> 
> -- with qemu-kvm-0.12.1.2-2.234.el6.x86_64
> 1. launch a win-7 guest directly with qemu-kvm without vdservice installed in
> guest
> 2. live migrate to a remote host
> 
> Result:
> Before migration, mouse works fine.
> After migration, mouse not work, just disappears. Mouse appears once vdservice
> gets installed but couldn't click. Mouse could click anywhere once start
> vdservice via 'net start vdservice'

Hi chayang,
- Does it always happen? Any special user behavior to reproduce it?
- When you notice that the cursor disappeared, have you tried to move the mouse and click it? (I'm wondering if maybe just the cursor disappeared, but the mouse works - I'm looking at the qemu/qxl code, and it seems that after migration the cursor image is not reloaded when qxl is in compat mode).
- Does restarting spice client helps?
- Does it happen when using client mouse (vdservice is started)?

Thanks,
Yonit.


> 
> -- with qemu-kvm-0.12.1.2-2.234.el6.x86_64, libvirt-0.9.10-2.el6.x86_64
> Confirmed with reporter that he didn't install vdservice in guest.
> Repeat the steps mentioned by reporter without vdservice installed in guest.
> 
> Result:
> Exactly the same result as I mentioned above. That is:
> Before migration, mouse works fine.
> After migration, mouse not work, just disappears. Mouse appears once vdservice
> gets installed but couldn't click. Mouse could click anywhere once start
> vdservice via 'net start vdservice'

(In reply to comment #25)
> Here are some updates:
> 
> -- with qemu-kvm-0.12.1.2-2.234.el6.x86_64
> 1. launch a win-7 guest directly with qemu-kvm without vdservice installed in
> guest
> 2. live migrate to a remote host
> 
> Result:
> Before migration, mouse works fine.
> After migration, mouse not work, just disappears. Mouse appears once vdservice
> gets installed but couldn't click. Mouse could click anywhere once start
> vdservice via 'net start vdservice'
> 
> -- with qemu-kvm-0.12.1.2-2.234.el6.x86_64, libvirt-0.9.10-2.el6.x86_64
> Confirmed with reporter that he didn't install vdservice in guest.
> Repeat the steps mentioned by reporter without vdservice installed in guest.
> 
> Result:
> Exactly the same result as I mentioned above. That is:
> Before migration, mouse works fine.
> After migration, mouse not work, just disappears. Mouse appears once vdservice
> gets installed but couldn't click. Mouse could click anywhere once start
> vdservice via 'net start vdservice'

I manage to reproduce this scenario, but I'm not convinced it is the same bug that started this thread. The bug(s) that are described along the thread happen with client mouse, while I think this bug is specific to server mouse.
This last bug happens always since commit 524886534be130129, (qemu-kvm-0.12.1.2-2.176.el6) which fixed client mouse not working after migration. However, even when there is no vdagent active, this patch leads to loading spicevmc which leads spice-server to move to client-mouse mode -> which doesn't work since there is no vdagent in the guest.

(In reply to comment #27)
> (In reply to comment #25)
> > Result:
> > Before migration, mouse works fine.
> > After migration, mouse not work, just disappears. Mouse appears once vdservice
> > gets installed but couldn't click. Mouse could click anywhere once start
> > vdservice via 'net start vdservice'
> 
> Hi chayang,
> - Does it always happen? Any special user behavior to reproduce it?
>
 Yes, always happens. No special usr hehavior is needed. Just migrate VM after it boots up.

> - When you notice that the cursor disappeared, have you tried to move the mouse
> and click it? (I'm wondering if maybe just the cursor disappeared, but the
> mouse works - I'm looking at the qemu/qxl code, and it seems that after
> migration the cursor image is not reloaded when qxl is in compat mode).
>
The cursor disappeared, I have tried to move and click the mouse, but not work. Neither left click nor right click.

> - Does restarting spice client helps?
Not work.

> - Does it happen when using client mouse (vdservice is started)?
> 
Keeping vdservice running, before and after migration, this issue not happens.

> Thanks,
> Yonit.
>

As I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=787974#c28
It looks like this bug description contains two bug.
The first one is easy to reproduce: start spice with server mouse and migrate.
The second one is related to client mouse, and I still couldn't find in this thread how to reproduce it. So please, lets reproduce this one.

Regarding the first bug: it is related to #725965 and virtio-serial-bus not opening devices after migration.

(In reply to comment #30)
> As I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=787974#c28
> It looks like this bug description contains two bug.
> The first one is easy to reproduce: start spice with server mouse and migrate.
Yes, this one is easy to reproduce, just start spice with server mode and migrate. After migration, cursor is disappeared and couldn't be moved around, couldn't click in destination guest.

> The second one is related to client mouse, and I still couldn't find in this
> thread how to reproduce it. So please, lets reproduce this one.
> 
When vdservice is running, guest mouse works well, after migration, the mouse works well, too. This is from our test on qemu-kvm >= 234.

No, like Yonit said if you want this bug to deal with the first problem then it is a server or qemu problem, not a client problem. I'll take a look today and move this to the correct component.

Alon

According to comment25 and comment26, mark qa_ack+.

A simple summary
Qemu-kvm qe(Chayang) hits two problems in this issue.

1.Installed vdagent-win in guest, started vdservice, mouse lost.the following this issue bug, can not hit this issue >=234 as comment31 said.
Bug 796203 - spice client mouse doesn't work since 0.12.1.2-2.228 build(closed on qemu-234) 

2.This original bug.(chayang has confirmed to the reporter,the scenario is same)
1.Boot guest with spicevmc and without *vdagent-win* in guest installed.
2.Did migration 
Results:

Before migration, mouse works fine.
After migration, mouse not work, just disappears.

(In reply to comment #33)
> No, like Yonit said if you want this bug to deal with the first problem then it
> is a server or qemu problem, not a client problem. I'll take a look today and
> move this to the correct component.
> 
> Alon

Status?

I know the cause, need to discuss with Amit. This should solve it: (for upstream, but same in rhel6)

diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..ad7c80d 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -798,14 +798,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
         return ret;
     }
 
-    if (!use_multiport(port->vser)) {
-        /*
-         * Allow writes to guest in this case; we have no way of
-         * knowing if a guest port is connected.
-         */
-        port->guest_connected = true;
-    }
-
     port->elem.out_num = 0;
 
     QTAILQ_INSERT_TAIL(&port->vser->ports, port, next);

(In reply to comment #36)
> I know the cause, need to discuss with Amit. This should solve it: (for
> upstream, but same in rhel6)
> 
> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
> index e22940e..ad7c80d 100644
> --- a/hw/virtio-serial-bus.c
> +++ b/hw/virtio-serial-bus.c
> @@ -798,14 +798,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
>          return ret;
>      }
> 
> -    if (!use_multiport(port->vser)) {
> -        /*
> -         * Allow writes to guest in this case; we have no way of
> -         * knowing if a guest port is connected.
> -         */
> -        port->guest_connected = true;
> -    }
> -
>      port->elem.out_num = 0;
> 
>      QTAILQ_INSERT_TAIL(&port->vser->ports, port, next);

This will only help pre-virtio-serial code; unless you're using port 0 (which is reserved for console ports), I don't see how this can help anything.

http://patchwork.ozlabs.org/patch/154390/
http://patchwork.ozlabs.org/patch/154391/

Just to be clear (sorry for the double mail): already backported to RHEL and verified the fix, just waiting for it to settle upstream before posting locally. So no patches in RHEL yet but I expect them soon (talked with Amit offline and he is happy with the fix - in fact most of it is sent by him).

Alon

Reproduction:
-------------
Reproduced this issue in env below. 
# rpm -q qemu-kvm;uname -r
qemu-kvm-0.12.1.2-2.288.el6.x86_64
2.6.32-269.el6.x86_64 

Steps:
1. launch a win-7 guest directly with qemu-kvm without vdservice installed in
guest
2. live migrate to a remote host

Result:
Before migration, mouse worked fine, could move and click.
After migration, mouse not work, just disappeared, could not move or click.


Verification:
-------------
Verified in env below with same steps as above.
# rpm -q qemu-kvm;uname -r
qemu-kvm-0.12.1.2-2.290.el6.x86_64
2.6.32-269.el6.x86_64

Result:
Before migration, mouse worked fine, could move and click.
After migration, mouse worked fine, could move and click. Same behaviour as before migration. 

Additional testing:
Start vdservice in guest, mouse worked fine, ping-pong migrated guest, any abnormal was not observed.


Conclusion:
-----------
As per above, this bug has been fixed.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
[NEEDINFO: Alon, could you please add this CCFR? Thanks!]

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,7 @@
-[NEEDINFO: Alon, could you please add this CCFR? Thanks!]+Cause: virtio-serial device marked the guest driver present bit on startup even without a guest present.
+
+Consequence: on destination of migration this bit being set caused spice to assume there is a guest agent, thereby disabeling server side mouse and causing mouse to be unusable if no agent was really running.
+
+Fix: the guest driver present bit is not set only if there is a working guest driver, so it is clear on startup.
+
+Result: when no guest agent is running mouse continues to work after migration.

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-2012-0746.html