[Engine-devel] Guest Reboot

[Omer Frenkel]

----- Original Message -----
> From: "Martin Betak" <mbetak at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, June 10, 2013 1:29:29 PM
> Subject: Re: [Engine-devel] Guest Reboot
> 
> 
> 
> 
> 
> ----- 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.
> 

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