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