[libvirt] [PATCH v2 1/1] qemu: hide details of fake reboot

nshirokovskiy nshirokovskiy at virtuozzo.com
Wed Apr 8 14:36:43 UTC 2020

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 at 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.

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.


More information about the libvir-list mailing list