Bug 1083478
| Summary: | The guest show dark screen after S3 when migrate guest from rhel6.5 host to rhel7 host | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | zhenfeng wang <zhwang> | ||||||
| Component: | qemu-kvm | Assignee: | Amit Shah <amit.shah> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.0 | CC: | dyuan, hhuang, huding, jdenemar, jen, juzhang, lersek, mrezanin, mzhan, pbonzini, qzhang, rbalakri, virt-bugs, virt-maint, xfu, ydu, zhwang, zpeng | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-09-19 06:36:49 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 923626 | ||||||||
| Attachments: |
|
||||||||
Seems like the guest died after S3 for some reason. Is there anything in /var/log/libvirt/qemu/rhel7.log on the destination? And debug logs from libvirtd on the destination could help too. Didn't find anything usefull in /var/log/libvirt/qemu/rhel7.log, find an error in libvirtd.log on the destination, i'll paste the logs to the attachment later, hope you can find more usefull info. cat libvirtd.log -- 014-04-03 01:56:10.124+0000: 22785: error : qemuMigrationCookieXMLParse:878 : internal error: Unsupported migration cookie feature persistent Created attachment 882061 [details]
The qemu guest's log and libvirtd log
Hmm, everything seems to be OK from libvirt's point of view. The "Unsupported migration cookie feature persistent" is a result of a bug on RHEL-6 libvirt, which sends persistent XML in the cookie even though VIR_MIGRATE_PERSIST_DEST was not used. But this is harmless. I'm moving this bug to qemu-kvm for further investigation. Anyway, does the bug reproduce on a domain with vnc graphics instead of spice or if you change video to be something else than qxl? Hi jiri There was exsiting qemu bugs 892412 & 1043379 about doing S3 with vnc graphics or spice with other video types （spice+vga, spice+cirrus）in rhel7 , so we can't decide whether this bug also reproduce on a domain with vnc graphics or spice with other video types else than qxl. BTW, i try to do S3 with spice+qxl on rhel7 host with rhel7 guest alone, it works as expect. only the issue in comment0 happens while i do the migration from rhel6 host to rhel7 host. What machine type do you use for the guest you run on rhel7? If it's the default one, could you try changing it to rhel6.5.0 and retry. In other words, I'd like to check if it depends on the machine type or if it's really only migration that triggers it. I use the default one and i can also do the S3 successfully while change the guest machine type to rhel6.5.0 I migrate a win8-64 guest from RHEL6.5 host to RHEL7.0 host, after migration, do S3/S4, hit this issue and the guest show dark screen. Version-Release number of selected component (if applicable): RHEL6.5 host: kernel-2.6.32-456.el6.x86_64 qemu-kvm-0.12.1.2-2.423.el6.x86_64 RHEL7.0 host: kernel-3.10.0-121.el7.x86_64 qemu-kvm-1.5.3-60.el7.x86_64 In guest, update qxl drvier to qxlwddm-0.3-2 The command line of src RHEL6.5 host: # /usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Westmere -enable-kvm -m 2048 -realtime mlock=off -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/mnt/win8-64-bak.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x13,indirect_desc=on,event_idx=off,hotplug=on,num_queues=1,max_sectors=512,cmd_per_lun=16,multifunction=on,rombar=64,param_change=on -device scsi-hd,drive=drive-system-disk,bus=scsi0.0,scsi-id=0,lun=0,id=data-disk2,logical_block_size=512,physical_block_size=512,min_io_size=512,opt_io_size=512,discard_granularity=512,ver=fuxc-scsi,serial=fuxc-scsi-serial,removable=off,wwn=0x16,channel=0,scsi-id=2,lun=0,bootindex=0 -vnc :10 -monitor stdio -nodefconfig -net none -spice port=5901,password=redhat-vga,disable-ticketing -vga qxl -global qxl-vga.vram_size=33554432 The command line of dest RHEL7.0 host: # /usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Westmere -enable-kvm -m 2048 -realtime mlock=off -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/mnt/win8-64-bak.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x13,indirect_desc=on,event_idx=off,hotplug=on,num_queues=1,max_sectors=512,cmd_per_lun=16,multifunction=on,rombar=64,param_change=on -device scsi-hd,drive=drive-system-disk,bus=scsi0.0,scsi-id=0,lun=0,id=data-disk2,logical_block_size=512,physical_block_size=512,min_io_size=512,opt_io_size=512,discard_granularity=512,ver=fuxc-scsi,serial=fuxc-scsi-serial,removable=off,wwn=0x16,channel=0,scsi-id=2,lun=0,bootindex=0 -vnc :10 -monitor stdio -nodefconfig -net none -spice port=5901,password=redhat-vga,disable-ticketing -vga qxl -global qxl-vga.vram_size=33554432 -incoming tcp:0:5800 See bug 1027565 comment 53 -- bug 1083478 (ie. this one) can likely be closed as a duplicate. Since the bug 1027565 will be fixed in qemu-kvm-1.5.3-61.el7 , so I think we'd better re-try this bug when the qemu-kvm-1.5.3-61.el7 come out Hi Laszlo I can still reproduce this bug with the qemu-kvm-1.5.3-60.el7_0.2 or qemu-kvm-rhev-1.5.3-60.el7_0.2, the following was my testing steps pkginfo source host libvirt-0.10.2-29.el6_5.8.x86_64 kernel-2.6.32-463.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.425.el6.x86_64 seabios-0.6.1.2-28.el6.x86_64 target host qemu-kvm-rhev-1.5.3-60.el7ev_0.2.x86_64 kernel-3.10.0-123.el7.x86_64 libvirt-1.1.1-29.el7.x86_64 seabios-1.7.2.2-12.el7.x86_64 seabios-bin-1.7.2.2-12.el7.x86_64 guest info guest os: rhel7 qemu-ga: qemu-guest-agent-1.5.3-60.el7_0.2.x86_64.rpm steps My test steps and result was the same with the comment0. I got some info from the qemu log on the target rhel7 host, hope it's helpfull for you #tail /var/log/libvirt/qemu/rhel7.log 2014-05-20 03:02:42.897+0000: shutting down qemu: terminating on signal 15 from pid 9486 2014-05-20 03:03:06.447+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name rhel7 -S -machine rhel6.5.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid e8be976a-023d-449e-0b37-1761bd2a309c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -boot strict=on -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/zhwang/img/rhel7.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:83:e5:23,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 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/rhel7.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -spice port=5901,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -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:[::]:49152 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 char device redirected to /dev/pts/4 (label charserial0) red_dispatcher_loadvm_commands: copying E and F segments from pc.bios to pc.ram copying C and D segments from pc.rom to pc.ram main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 0.145000 ms, bitrate 20686868686 bps (19728.535353 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: red_channel_client_disconnect: rcc=0x7fb89a29e2b0 (channel=0x7fb899ff0900 type=3 id=0) red_channel_client_disconnect: rcc=0x7fb830243c50 (channel=0x7fb83021f360 type=2 id=0) red_channel_client_disconnect: rcc=0x7fb8302b0ea0 (channel=0x7fb83021f930 type=4 id=0) red_channel_client_disconnect: rcc=0x7fb89a2ee980 (channel=0x7fb899fe4bd0 type=1 id=0) main_channel_client_on_disconnect: rcc=0x7fb89a2ee980 red_client_destroy: destroy client 0x7fb89a1b6600 with #channels=4 red_dispatcher_disconnect_cursor_peer: red_dispatcher_disconnect_display_peer: qemu: terminating on signal 15 from pid 9486 2014-05-20 03:05:34.695+0000: shutting down ~ (In reply to zhenfeng wang from comment #14) > Hi Laszlo > I can still reproduce this bug with the qemu-kvm-1.5.3-60.el7_0.2 or > qemu-kvm-rhev-1.5.3-60.el7_0.2, the following was my testing steps > copying E and F segments from pc.bios to pc.ram > copying C and D segments from pc.rom to pc.ram It's a separate issue then. Thank you for checking. Hi Huding, Can you handle this issue? Best Regards, Junyi (In reply to juzhang from comment #17) > Hi Huding, > > Can you handle this issue? > > Best Regards, > Junyi I test the following version: RHEL6 host: kernel-2.6.32-431.25.1.el6.x86_64 qemu-kvm-0.12.1.2-2.415.el6_5.12.x86_64 RHEL7 host: kernel-3.10.0-123.6.2.el7.x86_64 qemu-kvm-1.5.3-66.el7.x86_64 The kernel of RHEL7 guest is kernel-3.10.0-133.el7.x86_64 Migrate a RHEL7 guest from RHEL6.5 host to RHEL7 host, do S3 inside guest, the results are as following Video driver Result of S3 ============ ============================================== cirrus cannot resume and cannot ping guest[1] std cannot resume and cannot ping guest[2] qxl the guest call trace and the guest reboot[3] [1] After doing S3, the screenshot as the attachment file "cirrus_s3_screenshot.png". [2] After doing S3, the screen is dark. [3] The call trace log as following [ 0.497743] [drm:qxl_check_device] *ERROR* bad rom signature 0 [ 0.500365] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 0.501251] IP: [<ffffffffa010c18d>] setup_slot+0x34/0xea7 [qxl] [ 0.501251] PGD 0 [ 0.501251] Oops: 0002 [#1] SMP [ 0.501251] Modules linked in: qxl(+) drm_kms_helper ttm drm i2c_core ata_piix libata floppy dm_mirror dm_region_hash dm_log dm_mod [ 0.501251] CPU: 0 PID: 232 Comm: systemd-udevd Not tainted 3.10.0-133.el7.x86_64 #1 [ 0.501251] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 [ 0.501251] task: ffff880031be5b00 ti: ffff88002e7ce000 task.ti: ffff88002e7ce000 [ 0.501251] RIP: 0010:[<ffffffffa010c18d>] [<ffffffffa010c18d>] setup_slot+0x34/0xea7 [qxl] [ 0.501251] RSP: 0018:ffff88002e7cfa80 EFLAGS: 00010202 [ 0.501251] RAX: ffffc900000b4000 RBX: 0000000000000010 RCX: 0000000038000000 [ 0.501251] RDX: 0000000038000000 RSI: 0000000000000000 RDI: ffff88002e7e2000 [ 0.501251] RBP: ffff88002e7cfaa0 R08: ffff8800328b5400 R09: 0000000180080007 [ 0.501251] R10: ffffea0000ca2d00 R11: ffffffff812b8359 R12: ffff88002e7e2000 [ 0.501251] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8800329c5b20 [ 0.501251] FS: 00007f2cdb5dc880(0000) GS:ffff880034c00000(0000) knlGS:0000000000000000 [ 0.501251] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.501251] CR2: 0000000000000020 CR3: 000000002e7ec000 CR4: 00000000000406b0 [ 0.501251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.501251] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 0.501251] Stack: [ 0.501251] ffff88002e7e2000 0000000000000000 0000000000000000 0000000000000000 [ 0.501251] ffff88002e7cfaf8 ffffffffa0102947 ffff880000000040 ffffffff00010000 [ 0.501251] 000000003c000000 000000003dffffff ffff880000000020 ffff880000008000 [ 0.501251] Call Trace: [ 0.501251] [<ffffffffa0102947>] qxl_device_init+0x5b7/0x660 [qxl] [ 0.501251] [<ffffffffa0102b63>] qxl_driver_load+0x63/0xc0 [qxl] [ 0.501251] [<ffffffffa00a02e9>] drm_get_pci_dev+0x129/0x2e0 [drm] [ 0.501251] [<ffffffffa01022ab>] qxl_pci_probe+0x1b/0x40 [qxl] [ 0.501251] [<ffffffff812eb095>] local_pci_probe+0x45/0xa0 [ 0.501251] [<ffffffff812ec485>] ? pci_match_device+0xc5/0xd0 [ 0.501251] [<ffffffff812ec5c9>] pci_device_probe+0xf9/0x150 [ 0.501251] [<ffffffff813b6ca7>] driver_probe_device+0x87/0x390 [ 0.501251] [<ffffffff813b7083>] __driver_attach+0x93/0xa0 [ 0.501251] [<ffffffff813b6ff0>] ? __device_attach+0x40/0x40 [ 0.501251] [<ffffffff813b4a33>] bus_for_each_dev+0x73/0xc0 [ 0.501251] [<ffffffff813b66fe>] driver_attach+0x1e/0x20 [ 0.501251] [<ffffffff813b6250>] bus_add_driver+0x200/0x2d0 [ 0.501251] [<ffffffff813b7704>] driver_register+0x64/0xf0 [ 0.501251] [<ffffffff812ec2f5>] __pci_register_driver+0xa5/0xc0 [ 0.501251] [<ffffffffa0116000>] ? 0xffffffffa0115fff [ 0.501251] [<ffffffffa00a05ba>] drm_pci_init+0x11a/0x130 [drm] [ 0.501251] [<ffffffffa0116000>] ? 0xffffffffa0115fff [ 0.501251] [<ffffffffa011603e>] qxl_init+0x3e/0x1000 [qxl] [ 0.501251] [<ffffffff810020e2>] do_one_initcall+0xe2/0x190 [ 0.501251] [<ffffffff810ca98b>] load_module+0x12ab/0x1aa0 [ 0.501251] [<ffffffff812da6d0>] ? ddebug_proc_write+0xf0/0xf0 [ 0.501251] [<ffffffff810c72b3>] ? copy_module_from_fd.isra.43+0x53/0x150 [ 0.501251] [<ffffffff810cb336>] SyS_finit_module+0xa6/0xd0 [ 0.501251] [<ffffffff815f2f19>] system_call_fastpath+0x16/0x1b [ 0.501251] Code: 50 48 89 e5 41 56 41 55 41 88 f5 41 54 49 89 fc 53 44 02 68 40 41 0f b6 dd 45 0f b6 f5 48 c1 e3 05 48 03 9f 48 07 00 00 44 89 f6 <48> 89 4b 10 48 89 53 08 48 8b 87 38 07 00 00 48 89 90 9c 14 00 [ 0.501251] RIP [<ffffffffa010c18d>] setup_slot+0x34/0xea7 [qxl] [ 0.501251] RSP <ffff88002e7cfa80> [ 0.501251] CR2: 0000000000000020 [ 0.565159] ---[ end trace 6dd0aa24edf93db0 ]--- [ 0.566017] Kernel panic - not syncing: Fatal exception [ 0.566959] Rebooting in 10 seconds..[ 0.328399] ioremap error for 0xdfffe000-0xe0000000, requested 0x10, got 0x0 [ 1.688085] end_request: I/O error, dev fd0, sector 0 [ 1.710040] end_request: I/O error, dev fd0, sector 0 [ OK ] Started LSB: Start the iprupdate utility. [ OK ] Started LSB: Start the ipr dump daemon. [ OK ] Started Dynamic System Tuning Daemon. [ OK ] Started firewalld - dynamic firewall daemon. Starting Network Manager... [ OK ] Started Network Manager. Starting LSB: Bring up/down networking... Additional info: The command line of qxl driver is as following: /usr/libexec/qemu-kvm -cpu SandyBridge \ -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 \ -monitor stdio \ -M rhel6.5.0 \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 \ -drive file=/mnt/rhel7-test.qcow2,if=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,media=disk \ -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bus=pci.0,addr=0x4,bootindex=1 \ -netdev tap,id=hostnet0,vhost=on,id=hostnet0,script=/etc/qemu-ifup \ -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=c2:9a:2f:9c:de:10,bus=pci.0,addr=0x5 \ -qmp tcp:0:4445,server,nowait \ -serial unix:/tmp/tty0,server,nowait \ -spice port=5901,password=redhat-vga,disable-ticketing -vga qxl -global qxl-vga.vram_size=33554432 The command line of cirrus driver is as following: /usr/libexec/qemu-kvm -cpu SandyBridge \ -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 \ -monitor stdio \ -M rhel6.5.0 \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 \ -drive file=/mnt/rhel7-test.qcow2,if=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,media=disk \ -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bus=pci.0,addr=0x4,bootindex=1 \ -netdev tap,id=hostnet0,vhost=on,id=hostnet0,script=/etc/qemu-ifup \ -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=c2:9a:2f:9c:de:10,bus=pci.0,addr=0x5 \ -qmp tcp:0:4445,server,nowait \ -serial unix:/tmp/tty0,server,nowait \ -spice port=5901,password=redhat-vga,disable-ticketing -vga cirrus The command line of std driver is as following: /usr/libexec/qemu-kvm -cpu SandyBridge \ -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 \ -monitor stdio \ -M rhel6.5.0 \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 \ -drive file=/mnt/rhel7-test.qcow2,if=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,media=disk \ -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bus=pci.0,addr=0x4,bootindex=1 \ -netdev tap,id=hostnet0,vhost=on,id=hostnet0,script=/etc/qemu-ifup \ -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=c2:9a:2f:9c:de:10,bus=pci.0,addr=0x5 \ -qmp tcp:0:4445,server,nowait \ -serial unix:/tmp/tty0,server,nowait \ -spice port=5901,password=redhat-vga,disable-ticketing -vga std Created attachment 918085 [details]
The screenshot after doing S3 when video driver is cirrus
|
Description of problem: The guest show dark screen after S3 when migrate guest from rhel6.5 host to rhel7 host Version-Release number of selected component (if applicable): 6.5 host(source) kernel-2.6.32-431.11.1.el6.x86_64 libvirt-0.10.2-29.el6_5.7.x86_64 qemu-kvm-rhev-0.12.1.2-2.415.el6_5.5.x86_64 7.0 host (target) libvirt-1.1.1-29.el7.x86_64 qemu-kvm-rhev-1.5.3-59.el7ev.x86_64 kernel-3.10.0-115.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. set setenforce 1 && virt_use_nfs 1 (on both source and target) 2.Prepare a guest which the image file is on the NFS server,and mount the nfs server on both source and target 3.Start the guest on source, then install the qemu-guest-agent service in the guest #virsh dumpxml rhel7 -- <pm> <suspend-to-mem enabled='yes'/> <suspend-to-disk enabled='yes'/> </pm> -- <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/rhel7.agent'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> <graphics type='spice' autoport='yes'/> # virsh list Id Name State ---------------------------------------------------- 2 rhel7 running 4.Migrate the guest to the target #virsh migrate --live rhel7 qemu+ssh://10.66.106.35/system --verbose 5.Do S3 with the guest after finish migrate,The guest show dark screen after S3 even if the command excute successfully. # virsh dompmsuspend rhel7 --target mem Domain rhel7 successfully suspended # virsh list Id Name State ---------------------------------------------------- 2 rhel7 pmsuspended #virt-viewer rhel7 ===> show dark screen here Wakeup the guest #virsh dompmwakeup rhel7 Domain rhel7 successfully woken up # virsh list Id Name State ---------------------------------------------------- 2 rhel7 running #virt-viewer rhel7 ===> still show dark screen #ping $guest_ip ====> can't connect the guest 6.Destroy the guest on the target, then restart the guest in the source and re-migrate the guest to the target 7.Do S4 with the guest after finish migrate, The guest hiberate correctly in the target # virsh list Id Name State ---------------------------------------------------- 2 rhel7 running # virsh dompmsuspend rhel7 --target disk Domain rhel7 successfully suspended # virsh list Id Name State ---------------------------------------------------- 8.Restart the guest in the source host, the guest will back to the place where it left on the target this should be the expect result. 9.Both S3 and S4 works well if i only do it on rhel6 alone or on rhel7 alone 10. Run pm-hiberate in the guest, the guest hiberate correctly in the target Run pm-suspend in the guest, the guest show dark screen and hang there in the target Actual results: The guest show dark screen after S3 when migrate guest from rhel6.5 host to rhel7 host Expected results: should do s3 successfully while migrate guest from rhel6.5 to rhel7 host Additional info: