On 08.04.2020 16:08, Don Koch wrote: > 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 <nshirokovskiy@xxxxxxxxxxxxx> >>> >>> 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. The point of the patch was to hide these details from client. Just like in case of internal reboot - you will not see suspend/resume events. > > 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)? > AFAIU from libvirt POV there should be no issues. I can's say for QEMU though. Nikolay
