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 729869 - qxl: primary surface not saved on migration
Summary: qxl: primary surface not saved on migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Yonit Halperin
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 729240 (view as bug list)
Depends On:
Blocks: 728234 790083
TreeView+ depends on / blocked
 
Reported: 2011-08-11 06:17 UTC by Alon Levy
Modified: 2013-01-10 00:13 UTC (History)
9 users (show)

Fixed In Version: qemu-kvm-0.12.1.2-2.181.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 790083 (view as bug list)
Environment:
Last Closed: 2011-12-06 15:56:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
dirty the primary surface as well as the offscreens so all are migrated (2.84 KB, patch)
2011-08-11 06:17 UTC, Alon Levy 		no flags Details | Diff
Logs printed in the qemu monitor (5.44 KB, text/plain)
2011-08-26 08:44 UTC, Qunfang Zhang 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1531 0 normal SHIPPED_LIVE Moderate: qemu-kvm security, bug fix, and enhancement update 2011-12-06 01:23:30 UTC

Description Alon Levy 2011-08-11 06:17:28 UTC 
Created attachment 517737 [details]
dirty the primary surface as well as the offscreens so all are migrated

Description of problem:
When migrating the primary surface of the qxl graphics device is not saved, causing possible rendering artifacts on the target.
Comment 1 Dor Laor 2011-08-11 12:43:08 UTC 
Should that be a RHEV beta blocker or the artifacts are minor?
Comment 2 juzhang 2011-08-11 12:49:44 UTC 
Hi,Alon

   Would you please provides efficient way for qe to reproduce and verify this
issue? The detailed steps and explanation are welcome,thanks
Comment 3 Alon Levy 2011-08-11 12:59:47 UTC 
Dor, Juzhang,

 I have not seen the artifacts in question. I don't know if that means they are minor or I just missed it. Theoretically it could be totally wrong, if the guest doesn't update it.

 Juzhang, that also means I don't know how to reproduce - I mean, you could do many migrations and do a screendump after each one (via qemu monitor) and you should see non identical data.

 That said, I'll feel a lot better with this in.

Alon
Comment 6 Yonit Halperin 2011-08-14 05:40:41 UTC 
*** Bug 729240 has been marked as a duplicate of this bug. ***
Comment 7 Yonit Halperin 2011-08-14 05:57:18 UTC 
(In reply to comment #2)
> Hi,Alon
> 
>    Would you please provides efficient way for qe to reproduce and verify this
> issue? The detailed steps and explanation are welcome,thanks

Hi Juzhang,
In order to reproduce, you need to make the guest update the primary screen
during the migration. For example, browse to a website with dynamic content and
open some menus at the same time. When migration is complete and the spice
client has reconnected to the target, you should see that the display screen is
wrong.

Yonit.
Comment 9 Qunfang Zhang 2011-08-15 09:25:40 UTC 
(In reply to comment #7)
> (In reply to comment #2)
> > Hi,Alon
> > 
> >    Would you please provides efficient way for qe to reproduce and verify this
> > issue? The detailed steps and explanation are welcome,thanks
> 
> Hi Juzhang,
> In order to reproduce, you need to make the guest update the primary screen
> during the migration. For example, browse to a website with dynamic content and
> open some menus at the same time. When migration is complete and the spice
> client has reconnected to the target, you should see that the display screen is
> wrong.
> 
> Yonit.

Hi, Yonit
Thanks for your information. I test according to your steps but hit the bug 728984.

Steps:
1. Boot a RHEL6.1 guest
/usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usb -device usb-tablet -drive file=/mnt/RHEL6.1-32-virtio-desktop.qcow2,format=qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=00:10:2a:25:1b:50,bus=pci.0,addr=0x6 -boot c -uuid 7d955163-2ddd-4711-9347-ce6180998070 -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -name win7-32 -spice port=5930,disable-ticketing -vga qxl

2.Start in dst host with listening mode.

3.Open a website with dynamic content, like: http://www.jiujiuba.com/picnews/shownews.asp?infoid=1363

4.Implement migration, at the same time I keep clicking some buttons/menus inside guest.

Result: Guest finish migration and no obvious problem found. And I hit an abouted once. the logs are the same as Bug 728984.

I will continue to try it. btw,Yonit, could you tell me what is the meaning of "you should see that the display screen is wrong"? And could you give me some suggestions? Thanks a lot!
Comment 11 Qunfang Zhang 2011-08-24 05:16:55 UTC 
Hi,Alon and Yonit
I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem after migration.
I open a dynamic website or run the 2Dtom inside guest, then implement migration. And after migration, I found the guest screen in destination host is not active any more and pause about 5 seconds. The screen becomes quiescent instead of dynamic. For the guest running 2Dtom, after migration, it paused a few seconds and then becomes active again but still has problem. The 2Dtom dynamic pictures changes very slow.
Comment 12 Qunfang Zhang 2011-08-24 05:19:22 UTC 
CLI I used for Comment 11:
/usr/libexec/qemu-kvm -M rhel6.2.0 -cpu cpu64-rhel6,+x2apic  -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name RHEL6 -uuid 7d955163-2ddd-4711-9347-ce6180998070 -monitor stdio -rtc base=localtime -boot c -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive file=/mnt/win7-32-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:10:20:54,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/tmp/foo,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -usb -spice port=5930,disable-ticketing -k en-us -vga qxl -global qxl-vga.vram_size=67108864

I will change the status to ASSIGNED.

qzhang -> Alon, Yonit
Could you help have a look?  Any question please add comment or ping me.  Thanks!
Comment 13 Yonit Halperin 2011-08-24 05:42:00 UTC 
(In reply to comment #11)
> Hi,Alon and Yonit
> I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> after migration.
> I open a dynamic website or run the 2Dtom inside guest, then implement
> migration. And after migration, I found the guest screen in destination host is
> not active any more and pause about 5 seconds. The screen becomes quiescent
> instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> few seconds and then becomes active again but still has problem. The 2Dtom
> dynamic pictures changes very slow.
It is not the scope of this bug
1) I believe the pause is a result of switching hosts (no support for client seamless migration yet). see bug 730645
2) The slowness might be a bug. But a new one.
I think this bug can be moved again to ON_QA or VERIFIED.
Comment 14 Qunfang Zhang 2011-08-24 09:31:18 UTC 
(In reply to comment #13)
> (In reply to comment #11)
> > Hi,Alon and Yonit
> > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > after migration.
> > I open a dynamic website or run the 2Dtom inside guest, then implement
> > migration. And after migration, I found the guest screen in destination host is
> > not active any more and pause about 5 seconds. The screen becomes quiescent
> > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > few seconds and then becomes active again but still has problem. The 2Dtom
> > dynamic pictures changes very slow.
> It is not the scope of this bug
> 1) I believe the pause is a result of switching hosts (no support for client
> seamless migration yet). see bug 730645
Hi, Yonit
For this phenomenon, I borrow 2 other hosts and re-test. And after migration the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard are unavailable. Wait for a few minutes, guest still have no reaction.

> 2) The slowness might be a bug. But a new one.
I create a new one Bug 732949.

> I think this bug can be moved again to ON_QA or VERIFIED.

And also, seems I meet this issue Bug 729869 once. Copying files inside guest during migration and there's a dynamic progress bar. After migration, on destination host, there's 2 progress bars inside guest. And a few seconds later, one disappears.

So, Yonit
Could you have a check?

The information of the new hosts I used:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
stepping	: 7
cpu MHz		: 3093.215
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 6185.15
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
Comment 15 Qunfang Zhang 2011-08-25 01:30:36 UTC 
> And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> during migration and there's a dynamic progress bar. After migration, on
> destination host, there's 2 progress bars inside guest. And a few seconds
> later, one disappears.
> 
I meet this phenomenon in the qemu-kvm-0.12.1.2-2.184.el6.x86_64. 

So, Yonit, is this the same reason as described in bug Comment 0? Or something else?
Comment 16 Yonit Halperin 2011-08-25 09:35:51 UTC 
(In reply to comment #15)
> > And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> > during migration and there's a dynamic progress bar. After migration, on
> > destination host, there's 2 progress bars inside guest. And a few seconds
> > later, one disappears.
> > 
> I meet this phenomenon in the qemu-kvm-0.12.1.2-2.184.el6.x86_64. 
> 
> So, Yonit, is this the same reason as described in bug Comment 0? Or something
> else?
I doubt it is the same reason. I'm busy right now with other bugs. I will check it and let you know as soon as I can.
Comment 17 Yonit Halperin 2011-08-25 14:11:29 UTC 
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> > > Hi,Alon and Yonit
> > > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > > after migration.
> > > I open a dynamic website or run the 2Dtom inside guest, then implement
> > > migration. And after migration, I found the guest screen in destination host is
> > > not active any more and pause about 5 seconds. The screen becomes quiescent
> > > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > > few seconds and then becomes active again but still has problem. The 2Dtom
> > > dynamic pictures changes very slow.
> > It is not the scope of this bug
> > 1) I believe the pause is a result of switching hosts (no support for client
> > seamless migration yet). see bug 730645
> Hi, Yonit
> For this phenomenon, I borrow 2 other hosts and re-test. And after migration
> the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard
> are unavailable. Wait for a few minutes, guest still have no reaction.
> 
Can you please supply the src & target qemu logs? I want to see if the spice client connect the target before the vm was started.

> > 2) The slowness might be a bug. But a new one.
> I create a new one Bug 732949.
> 
Thanks. I reproduced it as well.
> > I think this bug can be moved again to ON_QA or VERIFIED.
> 
> And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> during migration and there's a dynamic progress bar. After migration, on
> destination host, there's 2 progress bars inside guest. And a few seconds
> later, one disappears.
> 
Can you reproduce it and (1) attach the src & target qemu logs. (2) manually connect to the paused src and see if spice display is the same one you see when spice has connected to the target when migration completed?


> So, Yonit
> Could you have a check?
> 
> The information of the new hosts I used:
> 
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 6
> model  : 42
> model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
> stepping : 7
> cpu MHz  : 3093.215
> cache size : 6144 KB
> physical id : 0
> siblings : 4
> core id  : 3
> cpu cores : 4
> apicid  : 6
> initial apicid : 6
> fpu  : yes
> fpu_exception : yes
> cpuid level : 13
> wp  : yes
> flags  : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
> constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf
> pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1
> sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts
> tpr_shadow vnmi flexpriority ept vpid
> bogomips : 6185.15
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
Comment 18 Qunfang Zhang 2011-08-26 08:43:30 UTC 
(In reply to comment #17)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > (In reply to comment #11)
> > > > Hi,Alon and Yonit
> > > > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > > > after migration.
> > > > I open a dynamic website or run the 2Dtom inside guest, then implement
> > > > migration. And after migration, I found the guest screen in destination host is
> > > > not active any more and pause about 5 seconds. The screen becomes quiescent
> > > > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > > > few seconds and then becomes active again but still has problem. The 2Dtom
> > > > dynamic pictures changes very slow.
> > > It is not the scope of this bug
> > > 1) I believe the pause is a result of switching hosts (no support for client
> > > seamless migration yet). see bug 730645
> > Hi, Yonit
> > For this phenomenon, I borrow 2 other hosts and re-test. And after migration
> > the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard
> > are unavailable. Wait for a few minutes, guest still have no reaction.
> > 
> Can you please supply the src & target qemu logs? I want to see if the spice
> client connect the target before the vm was started.
Hi, I boot the src & target guests with qemu command line and did not use management tool. So please check the attachment provided later to see if it is helpful. If not, could you tell me what I should do to get more log? 

> 
> > > 2) The slowness might be a bug. But a new one.
> > I create a new one Bug 732949.
> > 
> Thanks. I reproduced it as well.
> > > I think this bug can be moved again to ON_QA or VERIFIED.
> > 
> > And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> > during migration and there's a dynamic progress bar. After migration, on
> > destination host, there's 2 progress bars inside guest. And a few seconds
> > later, one disappears.
> > 
> Can you reproduce it and (1) attach the src & target qemu logs. (2) manually
> connect to the paused src and see if spice display is the same one you see when
> spice has connected to the target when migration completed?
I only meet this problem once, and tried many times, did not hit again. I will try more attempts.

>
Comment 19 Qunfang Zhang 2011-08-26 08:44:20 UTC 
Created attachment 520036 [details]
Logs printed in the qemu monitor
Comment 20 Yonit Halperin 2011-08-28 14:21:43 UTC 
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > (In reply to comment #11)
> > > > > Hi,Alon and Yonit
> > > > > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > > > > after migration.
> > > > > I open a dynamic website or run the 2Dtom inside guest, then implement
> > > > > migration. And after migration, I found the guest screen in destination host is
> > > > > not active any more and pause about 5 seconds. The screen becomes quiescent
> > > > > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > > > > few seconds and then becomes active again but still has problem. The 2Dtom
> > > > > dynamic pictures changes very slow.
> > > > It is not the scope of this bug
> > > > 1) I believe the pause is a result of switching hosts (no support for client
> > > > seamless migration yet). see bug 730645
> > > Hi, Yonit
> > > For this phenomenon, I borrow 2 other hosts and re-test. And after migration
> > > the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard
> > > are unavailable. Wait for a few minutes, guest still have no reaction.
> > > 
> > Can you please supply the src & target qemu logs? I want to see if the spice
> > client connect the target before the vm was started.
> Hi, I boot the src & target guests with qemu command line and did not use
> management tool. So please check the attachment provided later to see if it is
> helpful. If not, could you tell me what I should do to get more log? 
> 
Hi, what is the exact phenomenon: the guest is slow, or becomes inactive permanently?

> > 
> > > > 2) The slowness might be a bug. But a new one.
> > > I create a new one Bug 732949.
> > > 
> > Thanks. I reproduced it as well.
> > > > I think this bug can be moved again to ON_QA or VERIFIED.
> > > 
> > > And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> > > during migration and there's a dynamic progress bar. After migration, on
> > > destination host, there's 2 progress bars inside guest. And a few seconds
> > > later, one disappears.
> > > 
> > Can you reproduce it and (1) attach the src & target qemu logs. (2) manually
> > connect to the paused src and see if spice display is the same one you see when
> > spice has connected to the target when migration completed?
> I only meet this problem once, and tried many times, did not hit again. I will
> try more attempts.
o.k. If it is not reproducible, I suggest verifying this bug. But the other bugs you encountered are probably blockers.

> 
> >
Comment 21 Qunfang Zhang 2011-08-29 01:28:50 UTC 
(In reply to comment #20)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > (In reply to comment #14)
> > > > (In reply to comment #13)
> > > > > (In reply to comment #11)
> > > > > > Hi,Alon and Yonit
> > > > > > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > > > > > after migration.
> > > > > > I open a dynamic website or run the 2Dtom inside guest, then implement
> > > > > > migration. And after migration, I found the guest screen in destination host is
> > > > > > not active any more and pause about 5 seconds. The screen becomes quiescent
> > > > > > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > > > > > few seconds and then becomes active again but still has problem. The 2Dtom
> > > > > > dynamic pictures changes very slow.
> > > > > It is not the scope of this bug
> > > > > 1) I believe the pause is a result of switching hosts (no support for client
> > > > > seamless migration yet). see bug 730645
> > > > Hi, Yonit
> > > > For this phenomenon, I borrow 2 other hosts and re-test. And after migration
> > > > the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard
> > > > are unavailable. Wait for a few minutes, guest still have no reaction.
> > > > 
> > > Can you please supply the src & target qemu logs? I want to see if the spice
> > > client connect the target before the vm was started.
> > Hi, I boot the src & target guests with qemu command line and did not use
> > management tool. So please check the attachment provided later to see if it is
> > helpful. If not, could you tell me what I should do to get more log? 
> > 
> Hi, what is the exact phenomenon: the guest is slow, or becomes inactive
> permanently?
Migrate guest from host A to host B, the guest becomes inactive permanently. Keyboard and mouse are not available but the guest is alive. If I migrate it from B to A back, the guest may become active again.

> 
> > > 
> > > > > 2) The slowness might be a bug. But a new one.
> > > > I create a new one Bug 732949.
> > > > 
> > > Thanks. I reproduced it as well.
> > > > > I think this bug can be moved again to ON_QA or VERIFIED.
> > > > 
> > > > And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> > > > during migration and there's a dynamic progress bar. After migration, on
> > > > destination host, there's 2 progress bars inside guest. And a few seconds
> > > > later, one disappears.
> > > > 
> > > Can you reproduce it and (1) attach the src & target qemu logs. (2) manually
> > > connect to the paused src and see if spice display is the same one you see when
> > > spice has connected to the target when migration completed?
> > I only meet this problem once, and tried many times, did not hit again. I will
> > try more attempts.
> o.k. If it is not reproducible, I suggest verifying this bug. But the other
> bugs you encountered are probably blockers.
OK, then should we close this issue an reopen a new one for the problem above or need to investigate more about the other issue (inactive after migration)? 
> 
> > 
> > >
Comment 22 Yonit Halperin 2011-08-29 05:36:36 UTC 
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #18)
> > > (In reply to comment #17)
> > > > (In reply to comment #14)
> > > > > (In reply to comment #13)
> > > > > > (In reply to comment #11)
> > > > > > > Hi,Alon and Yonit
> > > > > > > I tested on qemu-kvm-0.12.1.2-2.184.el6.x86_64 and found it still has problem
> > > > > > > after migration.
> > > > > > > I open a dynamic website or run the 2Dtom inside guest, then implement
> > > > > > > migration. And after migration, I found the guest screen in destination host is
> > > > > > > not active any more and pause about 5 seconds. The screen becomes quiescent
> > > > > > > instead of dynamic. For the guest running 2Dtom, after migration, it paused a
> > > > > > > few seconds and then becomes active again but still has problem. The 2Dtom
> > > > > > > dynamic pictures changes very slow.
> > > > > > It is not the scope of this bug
> > > > > > 1) I believe the pause is a result of switching hosts (no support for client
> > > > > > seamless migration yet). see bug 730645
> > > > > Hi, Yonit
> > > > > For this phenomenon, I borrow 2 other hosts and re-test. And after migration
> > > > > the guest becomes inactive: 2Dtom becomes quiescent, both mouse and keyboard
> > > > > are unavailable. Wait for a few minutes, guest still have no reaction.
> > > > > 
> > > > Can you please supply the src & target qemu logs? I want to see if the spice
> > > > client connect the target before the vm was started.
> > > Hi, I boot the src & target guests with qemu command line and did not use
> > > management tool. So please check the attachment provided later to see if it is
> > > helpful. If not, could you tell me what I should do to get more log? 
> > > 
> > Hi, what is the exact phenomenon: the guest is slow, or becomes inactive
> > permanently?
> Migrate guest from host A to host B, the guest becomes inactive permanently.
> Keyboard and mouse are not available but the guest is alive. If I migrate it
> from B to A back, the guest may become active again.
I couldn't reproduce this. Are you able to reproduce it just by running 2DTom on the guest? Or is there a difference between this scenario to the slowness one?
If you close the client and then again open a spice client for the target, the guest is still inactive?
> 
> > 
> > > > 
> > > > > > 2) The slowness might be a bug. But a new one.
> > > > > I create a new one Bug 732949.
> > > > > 
> > > > Thanks. I reproduced it as well.
> > > > > > I think this bug can be moved again to ON_QA or VERIFIED.
> > > > > 
> > > > > And also, seems I meet this issue Bug 729869 once. Copying files inside guest
> > > > > during migration and there's a dynamic progress bar. After migration, on
> > > > > destination host, there's 2 progress bars inside guest. And a few seconds
> > > > > later, one disappears.
> > > > > 
> > > > Can you reproduce it and (1) attach the src & target qemu logs. (2) manually
> > > > connect to the paused src and see if spice display is the same one you see when
> > > > spice has connected to the target when migration completed?
> > > I only meet this problem once, and tried many times, did not hit again. I will
> > > try more attempts.
> > o.k. If it is not reproducible, I suggest verifying this bug. But the other
> > bugs you encountered are probably blockers.
> OK, then should we close this issue an reopen a new one for the problem above
> or need to investigate more about the other issue (inactive after migration)? 

I believe the above issue should be opened in another bug, or if it takes the same steps to reproduce it, add its description to bug 732949.
Thanks.
> > 
> > > 
> > > >
Comment 23 Qunfang Zhang 2011-08-29 05:49:31 UTC 
> > > Hi, what is the exact phenomenon: the guest is slow, or becomes inactive
> > > permanently?
> > Migrate guest from host A to host B, the guest becomes inactive permanently.
> > Keyboard and mouse are not available but the guest is alive. If I migrate it
> > from B to A back, the guest may become active again.
> I couldn't reproduce this. Are you able to reproduce it just by running 2DTom
> on the guest? Or is there a difference between this scenario to the slowness
> one?
> If you close the client and then again open a spice client for the target, the
> guest is still inactive?
Hi, Yonit
It is the same steps with the scenario to the slowness one. And maybe the issue is related the host hardware. I can not reproduce it with my HP 760 (Intel(R) Core(TM)2 Quad CPU Q9550  @ 2.83GHz). 

The host hw info to reproduce this issue is:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
stepping	: 7
cpu MHz		: 3093.206
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 6185.15
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:


> > 

> 
> I believe the above issue should be opened in another bug, or if it takes the
> same steps to reproduce it, add its description to bug 732949.

Hi, Yonit
Then I'd like to close this issue and add description to bug 732949. And let's track the problem in that bug.  Thanks~

> Thanks.
> > > 
> > > > 
> > > > >
Comment 24 Qunfang Zhang 2011-08-29 05:50:47 UTC 
Setting to VERIFIED according to Comment 20 and Comment 22. Will track the guest inactivation issue in Bug 732949.
Comment 26 errata-xmlrpc 2011-12-06 15:56:07 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/RHSA-2011-1531.html
Note You need to log in before you can comment on or make changes to this bug.