Bug 1258809 - It needs another time 'system_reset' to recover the guest after 'pm-hibernate'/'pm-suspend-hybrid' inside the guest
It needs another time 'system_reset' to recover the guest after 'pm-hibernate...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
ppc64le Unspecified
low Severity unspecified
: rc
: ---
Assigned To: David Gibson
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2015-09-01 06:31 EDT by Gu Nini
Modified: 2015-09-16 01:04 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-16 01:04:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
guest_consle_log (117.83 KB, text/plain)
2015-09-01 06:31 EDT, Gu Nini
no flags Details

  None (edit)
Description Gu Nini 2015-09-01 06:31:58 EDT
Created attachment 1068935 [details]

Description of problem:
After execute cmd 'pm-hibernate' or 'pm-suspend-hybrid' inside the guest, hmp cmds 'system_reset'/'cont' is not enough to recover the guest until the 2nd time 'system_reset'

Version-Release number of selected component (if applicable):
Host kernel: 3.10.0-306.0.1.el7.ppc64le
Guest kernel: 3.10.0-306.0.1.el7.ppc64le
Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-21.el7.ppc64le

How reproducible:

Steps to Reproduce:
1. Boot a guest with a console device, take following qemu cmd line as an example:

 -chardev socket,id=serial_id_serial0,path=/tmp/spaprqcow-0820,server,nowait -device spapr-vty,chardev=serial_id_serial0

2. Connect to the guest console with 'nc -U', then issue cmd 'pm-hibernate' or 'pm-suspend-hybrid' there
nc -U /tmp/spaprqcow-0820
[root@localhost ~]# 

[root@localhost ~]# pm-hibernate
3. Check/reset the guest status in hmp:
(qemu) info status
VM status: paused (shutdown)
(qemu) system_reset
(qemu) cont
(qemu) info status
VM status: running
4. Check the guest status in the guest console channel:
[    1.803489] dracut-initqueue[303]: inactive '/dev/rhel/swap' [2.00 GiB] inherit
[    1.803686] dracut-initqueue[303]: inactive '/dev/rhel/root' [17.46 GiB] inherit
[  OK  ] Found device /dev/mapper/rhel-root.
         Starting File System Check on /dev/mapper/rhel-root...
[  OK  ] Started File System Check on /dev/mapper/rhel-root.
[    1.928556] PM: Starting manual resume from disk
[    1.937651] Freezing user space processes ... (elapsed 0.001 seconds) done.
[    1.947252] PM: Using 3 thread(s) for decompression.
[    1.947252] PM: Loading and decompressing image data (10016 pages)...
[    3.083010] PM: Image loading progress:   0%
[    3.343663] PM: Image loading progress:  10%
[    3.434558] PM: Image loading progress:  20%
[    3.521117] PM: Image loading progress:  30%
[    3.601843] PM: Image loading progress:  40%
[    3.688510] PM: Image loading progress:  50%
[    3.772733] PM: Image loading progress:  60%
[    3.890322] PM: Image loading progress:  70%
[    4.007883] PM: Image loading progress:  80%
[    4.115871] PM: Image loading progress:  90%
[    4.249267] PM: Image loading progress: 100%
[    4.252663] PM: Image loading done.
[    4.252705] PM: Read 641024 kbytes in 2.30 seconds (278.70 MB/s)
[    4.254537] Suspending console(s) (use no_console_suspend to debug)


Actual results:
In steps 3/4, after reset the guest with hmp cmds 'system_reset'/'cont', the guest is still in 'Freezing/Suspending' status as showed in step 4; and the guest recovers well until another time 'system_reset'. For details, please refer to the attached 'guest_console_log'

Expected results:
No need the 2nd time hmp cmd 'system_reset' to let the guest recover to run

Additional info:

Note You need to log in before you can comment on or make changes to this bug.