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