On Wed, 8 Apr 2020 10:34:08 +0300 nshirokovskiy wrote: > > > On 07.04.2020 20:31, Don Koch wrote: > > On Thu, 19 Dec 2019 13:50:19 +0300 > > Nikolay Shirokovskiy wrote: > > > >> If we use fake reboot then domain goes thru running->shutdown->running > >> state changes with shutdown state only for short period of time. At > >> least this is implementation details leaking into API. And also there is > >> one real case when this is not convinient. I'm doing a backup with the > >> help of temporary block snapshot (with the help of qemu's API which is > >> used in the newly created libvirt's backup API). If guest is shutdowned > >> I want to continue to backup so I don't kill the process and domain is > >> in shutdown state. Later when backup is finished I want to destroy qemu > >> process. So I check if it is in shutdowned state and destroy it if it > >> is. Now if instead of shutdown domain got fake reboot then I can destroy > >> process in the middle of fake reboot process. > >> > >> After shutdown event we also get stop event and now as domain state is > >> running it will be transitioned to paused state and back to running > >> later. Though this is not critical for the described case I guess it is > >> better not to leak these details to user too. So let's leave domain in > >> running state on stop event if fake reboot is in process. > >> > >> Reconnection code handles this patch without modification. It detects > >> that qemu is not running due to shutdown and then calls > >> qemuProcessShutdownOrReboot > >> which reboots as fake reboot flag is set. > >> > >> Signed-off-by: Nikolay Shirokovskiy <nshirokovs...@virtuozzo.com> > > > > Question regarding this change: in the on-line documentation for > > virDomainReboot(), > > it states: > > > > Due to implementation limitations in some drivers (the qemu driver, > > for instance) it is not advised to migrate or save a guest that is > > rebooting as a result of this API. Migrating such a guest can lead to a > > plain shutdown on the destination. > > > > Is this still the case? > > Hi, Don. Yeah this is still the case. > > > In any event, how does one know when the reboot has > > finished (assuming the VM reacted to it)? > > Unfortunately there is no event for reboot. Before the patch there was > SHUTDOWN event but only when reboot is done thru ACPI. Now when fake > reboot impl is more incapsulated there is no more SHUTDOWN event just as > for reboot from guest. > > Nikolay > There was also a startup/resume event. Maybe add a reboot event at that point? I don't think anyone really cares about when the shutdown occurs but rather know about the resume.
A side question is: is there a problem with doing a migration if, say, the reboot was done internally (i.e. someone issued a "reboot" command from within the VM)? -d
