Re: [Engine-devel] Guest Reboot
----- Original Message -----
From: "Martin Betak" <mbetak(a)redhat.com>
To: "Omer Frenkel" <ofrenkel(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, June 10, 2013 1:29:29 PM
Subject: Re: [Engine-devel] Guest Reboot
----- Original Message -----
> From: "Omer Frenkel" <ofrenkel(a)redhat.com>
> To: "Martin Betak" <mbetak(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Sunday, June 9, 2013 8:51:54 AM
> Subject: Re: [Engine-devel] Guest Reboot
>
> As i understand it, reboot will do shutdown and initiate a run-command in
> order to send any updated parameters,
> if this is correct, why vdsm and GA need to know its a reboot? guest is
> shutting down, no?
Well in some cases where the VM configuration hasn't changed we can do
graceful reboot using
libvirt acpi reboot capabilities via guest agent (by just passing different
option to the existing shutdown script).
This preserves the qemu process and can be more efficient than the destroy();
start() sequence.
Of course if it were the case that the guest would not respond to graceful
method of reboot and the
power-down policy for this VM "hard", the engine would fall back to the
destroy(); start() sequence.
Otherwise (graceful-only reboot policy) we would leave the guest alone ->
status UP.
ok maybe worth adding this info to the wiki,
although currently there is no way to know if configuration has changed or not,
but should be something like this soon (RFE for changing running vm configuration)
>
> it would be better to add some info on stateless issue: when stateless vm
> goes down, its state is cleared,
> so need to decide if reboot to stateless means also start with new state or
> no.
I think this issue is similar to the Run-Once question.
Do we want to give the user another option to choose from or do we pick one
for him?
>
> similar is vm from pool: when vm from automatic pool goes down, it
> "returns"
> to the pool, and not belong to a specific user anymore,
> also here the state is cleared, so again need to understand the correct
> behaviour
>
In the case of vm from pool the state treatment should be the same as in
stateless but we also need
to run the stop(); start() sequence in a transaction to make sure nobody else
can "steal" this machine from this user.
Or possibly since pool-VM configuration cannot change we could perhaps do the
reboot only using the new vdsm capabilities.
Do you think this would be possible or the engine would "notice" that the VM
went Down for a brief moment?
engine have to identify the vm as down before starting it again..
Maybe a new VM state "Rebooting" instead of Down would help
in this case?
not sure this is the best approach, need to do some thinking about this