[Engine-devel] Guest Reboot

[Martin Betak]

----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Martin Betak" <mbetak at redhat.com>
> Cc: engine-devel at 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.

> 
> 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?
Maybe a new VM state "Rebooting" instead of Down would help in this case?