Thanks for splitting this issue out of our former work Sean.
I must admit I mostly use save/restore but less so suspend to ram - and even if 
so I don#t use the guest agent to do so, but all of that is worth testing.
I started with a repro of said case.

Usual updating to the latest versions of all packages - running on artful in 
host and guest.
Machine is a 

Just like you I added the xml and installed the pkg qemu-guest-agent
 <channel type='unix'>
   <target type='virtio' name='org.qemu.guest_agent.0'/>
 </channel>
Note: I never specify the target to get the defaults of libvirt also if you 
want you can hot-attach such a channel (for the sake of staying with the case I 
did like you did with shutdown and in the static guest xml).

As guest agent is not strictly required (unless you have custom
freezing/thaw operations) I did one guest to test with it and one
without.

For better debugging in regard to the case I added "debug no_console_suspend" 
and removed "quiet splash" kernel options in /etc/default/grub and ran 
update-grub in the guests.
Also set the guest agent to verbose via:
$ echo 'DAEMON_ARGS="--verbose --logfile=/var/log/qemu-ga.log"' | sudo tee 
/etc/default/qemu-guest-agent

Tested the guest agent prior to the actual suspend/resume tests.
Agent is active in the guest and happy also guest ping works:
$ sudo virsh qemu-agent-command artful-uvt-test-agent '{"execute":"guest-ping"}'
Also guest-info confirms that at least the agent "thinks" pm suspend should be 
supported:
$ sudo virsh qemu-agent-command artful-uvt-test-agent '{"execute":"guest-info"}'
[...]
{"enabled":true,"name":"guest-suspend-ram","success-response":false}

Also have to differ the suspend options on the two guest types I test.
There is:
- virsh suspend/resume - the host will do the suspend to memory
 (this is what is used mostly as the guest doesn't need anything to know about 
it)
- virsh dompmsuspend/dompmwakeup - goes through guest agent to call ACPI states 
- S3 for mem
  (less common in general as more setup is required)


As I assumed the outer suspend/resume - which is like a lock in time for the 
guest worked quite well. Reached paused state and woke up - no issues.
But as guests don't like that if you do this for a longer period of time I 
understand the need for dompmsuspend so lets get to that.

Note: you said you don't see it reaching a non running state - it should
reach "pmsuspended" state in your case if suspending correctly - so I'd
assume it failing on the suspend already.

Tracking on all kind of logs while doing suspend and resume now.
- host journal
- host dmesg
- host guest libvirt/qemu log
- guest console
- guest journal
- guest qemu-agent log

I get a success response from virsh (which only knows that it submitted the cmd 
- see response false in the general agent command).
$ virsh dompmsuspend artful-uvt-test-agent --target mem
Domain artful-uvt-test-agent successfully suspended

But just like you it stays in state "running" so something is incomplete.
The guest is dead thou so some freeze happened.
No other log even moved - the only thing is the guest agent, that says:

1513156829.72735: debug: read data, count: 59, data: {"execute":"guest-sync", 
"arguments":{"id":1513156829070}}
1513156829.72837: debug: process_event: called
1513156829.72928: debug: processing command
1513156829.73035: debug: sending data, count: 26
1513156829.73555: debug: read data, count: 32, data: 
{"execute":"guest-suspend-ram"}
1513156829.73648: debug: process_event: called
1513156829.73691: debug: processing command

Wow this already is quite a monologue :-/ I should press submit
sometimes :-)

Next step is that we have to debug the guest what it actually does:
1. what does the sync and suspend from the agent really call
2. is it meant to work on arm
3. debug the freeze step by step, maybe via 
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

** Changed in: qemu (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1737786

Title:
  (arm64) unable to dompmwakeup a vm after being suspended

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1737786/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to