On 03/12/2012 04:35 PM, Paolo Bonzini wrote:
Il 12/03/2012 06:13, Osier Yang ha scritto:
On 03/11/2012 10:37 PM, Paolo Bonzini wrote:
Il 05/03/2012 11:25, Osier Yang ha scritto:
This introduces a new paused reason VIR_DOMAIN_PAUSED_SUSPEND,
and new suspend event type VIR_DOMAIN_EVENT_SUSPENDED_SUSPEND.
While a SUSPEND event occurs, the running domain status will be
transferred to "paused" with reason "VIR_DOMAIN_PAUSED_SUSPEND",
and a new domain lifecycle event emitted with type
VIR_DOMAIN_EVENT_SUSPENDED_SUSPEND.
---
Does "virsh resume" correctly wakeup such a domain?
Ah, yes, I prohibited the situation waking up a domain which
wasn't paused by SUSPEND event. But here I forgot it.
If not, perhaps a
different state should be added so that "virsh resume" can look at the
state and issue the appropriate monitor command (or alternatively, it
could be considered a QEMU bug).
We have the paused reason. And the patch which should be
squashed in in the attachment.
From the patch:
+ qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("domain paused from guest side can't be resumed, "
+ "you might want to wakeup it"));
goto endjob;
This is not an internal error. It should have a precise error code so
that for example virsh can refer the user to dompmwakeup.
Yes, it was just a demo, I won't put it in the real code in the end, :-)
Personally I think that using just "virsh suspend"/"virsh resume" would
have been a fine user interface if you use the PAUSED state (with "virsh
suspend --pm" for example). Then there would have been no need for
"virsh dompmwakeup" at all.
There is still time to change it, but it needs to be done quite soon.
No luck, the patches for dompmsuspend were submitted Jan 26 (7c74176),
we already have a realease with it (0.9.10: Feb 13 2012).
BTW, another thing to test is what happens if you send "virsh suspend"
after putting the guest into S3.
The guest behaves no difference in this case, but I'm thinking if we
should prohibit a guest which was already put into s3 from guest side
too, in case of the confusion. Yeah, I think we need to do that.
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list