On Mon, Nov 30, 2020 at 14:45:18 -0500, Luna Xu wrote: > Hi developers, Hi, [...] > When I start a VM with the qemu command I can specify the -no-shutdown > flag so that my qemu process doesn't quit even if I shutdown the VM > from the inside (issue shutdown or halt command inside VM). The VM is > shutdown but the qemu process is not killed so that the jobs I > submitted before for example backup (drive-backup) can continue to run > even after VM gets shutdown by the user, and I'm able to check the > status of the job through qmp commands (by communicating with the qemu > process). As I've noted in my reply on libvirt-users, we currently don't support this on the shutdown part of the VM lifecycle. On the startup part you can use VIR_DOMAIN_START_PAUSED for a VM which didn't yet excecute any guest instructions. > Is anyone aware of any project that is currently implementing this > functionality? Thanks for reading. I don't think that there's anybody working on it. If you are interested in implementing the feature the idea would be to add a 'pause' action for <on_poweroff>pause</on_poweroff> along with a new 'virDomainPausedReason' such as VIR_DOMAIN_PAUSED_POWEROFF and implement the lifecycle transition from PAUSED -> RUNNING via qemuDomainResume, which would in this case have to issue a 'system-reset' qmp command and emit the appropriate events.

On Tue, Dec 01, 2020 at 15:34:05 +0100, Peter Krempa wrote: > On Mon, Nov 30, 2020 at 14:45:18 -0500, Luna Xu wrote: > > Hi developers, > > Hi, > > [...] > > > When I start a VM with the qemu command I can specify the -no-shutdown > > flag so that my qemu process doesn't quit even if I shutdown the VM > > from the inside (issue shutdown or halt command inside VM). The VM is > > shutdown but the qemu process is not killed so that the jobs I > > submitted before for example backup (drive-backup) can continue to run > > even after VM gets shutdown by the user, and I'm able to check the > > status of the job through qmp commands (by communicating with the qemu > > process). > > As I've noted in my reply on libvirt-users, we currently don't support > this on the shutdown part of the VM lifecycle. > > On the startup part you can use VIR_DOMAIN_START_PAUSED for a VM which > didn't yet excecute any guest instructions. > > > Is anyone aware of any project that is currently implementing this > > functionality? Thanks for reading. > > I don't think that there's anybody working on it. > > If you are interested in implementing the feature the idea would be to > add a 'pause' action for <on_poweroff>pause</on_poweroff> along with a > new 'virDomainPausedReason' such as VIR_DOMAIN_PAUSED_POWEROFF and > implement the lifecycle transition from PAUSED -> RUNNING via > qemuDomainResume, which would in this case have to issue a > 'system-reset' qmp command and emit the appropriate events. This is weird, the domain was paused just before being shut down so resuming it should logically just resume the paused process and finish the shutdown. On the other hand, domain shutdown as a result of calling resume is weird too. So how about just adding a check to qemuDomainResume to report an error if you try to resume a domain which was paused for shutdown? Jirka

On Tue, Dec 01, 2020 at 05:09:26PM +0100, Jiri Denemark wrote: > On Tue, Dec 01, 2020 at 15:34:05 +0100, Peter Krempa wrote: > > On Mon, Nov 30, 2020 at 14:45:18 -0500, Luna Xu wrote: > > > Hi developers, > > > > Hi, > > > > [...] > > > > > When I start a VM with the qemu command I can specify the -no-shutdown > > > flag so that my qemu process doesn't quit even if I shutdown the VM > > > from the inside (issue shutdown or halt command inside VM). The VM is > > > shutdown but the qemu process is not killed so that the jobs I > > > submitted before for example backup (drive-backup) can continue to run > > > even after VM gets shutdown by the user, and I'm able to check the > > > status of the job through qmp commands (by communicating with the qemu > > > process). > > > > As I've noted in my reply on libvirt-users, we currently don't support > > this on the shutdown part of the VM lifecycle. > > > > On the startup part you can use VIR_DOMAIN_START_PAUSED for a VM which > > didn't yet excecute any guest instructions. > > > > > Is anyone aware of any project that is currently implementing this > > > functionality? Thanks for reading. > > > > I don't think that there's anybody working on it. > > > > If you are interested in implementing the feature the idea would be to > > add a 'pause' action for <on_poweroff>pause</on_poweroff> along with a > > new 'virDomainPausedReason' such as VIR_DOMAIN_PAUSED_POWEROFF and > > > implement the lifecycle transition from PAUSED -> RUNNING via > > qemuDomainResume, which would in this case have to issue a > > 'system-reset' qmp command and emit the appropriate events. > > This is weird, the domain was paused just before being shut down so > resuming it should logically just resume the paused process and finish > the shutdown. On the other hand, domain shutdown as a result of calling > resume is weird too. > > So how about just adding a check to qemuDomainResume to report an error > if you try to resume a domain which was paused for shutdown? Note we have a virDomainReset() API that does a full machine/cpu reset, so if we're in the puased state after shutdown, then a reset followed by a resume is a valid way to boot the guest OS fresh. This is in fact how we fake graceful reboots. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Tue, Dec 01, 2020 at 17:53:30 +0000, Daniel P. Berrangé wrote: > On Tue, Dec 01, 2020 at 05:09:26PM +0100, Jiri Denemark wrote: > > On Tue, Dec 01, 2020 at 15:34:05 +0100, Peter Krempa wrote: > > > On Mon, Nov 30, 2020 at 14:45:18 -0500, Luna Xu wrote: > > > > Hi developers, > > > > > > Hi, > > > > > > [...] > > > > > > > When I start a VM with the qemu command I can specify the -no-shutdown > > > > flag so that my qemu process doesn't quit even if I shutdown the VM > > > > from the inside (issue shutdown or halt command inside VM). The VM is > > > > shutdown but the qemu process is not killed so that the jobs I > > > > submitted before for example backup (drive-backup) can continue to run > > > > even after VM gets shutdown by the user, and I'm able to check the > > > > status of the job through qmp commands (by communicating with the qemu > > > > process). > > > > > > As I've noted in my reply on libvirt-users, we currently don't support > > > this on the shutdown part of the VM lifecycle. > > > > > > On the startup part you can use VIR_DOMAIN_START_PAUSED for a VM which > > > didn't yet excecute any guest instructions. > > > > > > > Is anyone aware of any project that is currently implementing this > > > > functionality? Thanks for reading. > > > > > > I don't think that there's anybody working on it. > > > > > > If you are interested in implementing the feature the idea would be to > > > add a 'pause' action for <on_poweroff>pause</on_poweroff> along with a > > > new 'virDomainPausedReason' such as VIR_DOMAIN_PAUSED_POWEROFF and > > > > > implement the lifecycle transition from PAUSED -> RUNNING via > > > qemuDomainResume, which would in this case have to issue a > > > 'system-reset' qmp command and emit the appropriate events. > > > > This is weird, the domain was paused just before being shut down so > > resuming it should logically just resume the paused process and finish > > the shutdown. On the other hand, domain shutdown as a result of calling > > resume is weird too. > > > > So how about just adding a check to qemuDomainResume to report an error > > if you try to resume a domain which was paused for shutdown? > > Note we have a virDomainReset() API that does a full machine/cpu reset, > so if we're in the puased state after shutdown, then a reset followed > by a resume is a valid way to boot the guest OS fresh. This is in fact > how we fake graceful reboots. Sure, I just didn't want virDomainResume to automagically do the reset part. I guess you're suggesting that we should not report an error because virDomainReset would not change the domain state (or would it?) and thus reporting an error would block this scenario. So in that case, we should not report any error and in just try to resume the CPUs. In other words, this would mean no change is really needed in qemuDomainResume.