[ovirt-devel] [RFE] VM Pools allow stateful VMs

Sefi Litmanovich slitmano at redhat.com
Thu Apr 21 09:09:58 UTC 2016


Hi,

On 4.0 A new RFE is introduced that allows to define a VmPool as stateful
(up until now it was stateless by default) -
https://bugzilla.redhat.com/show_bug.cgi?id=1234394 .
A stateful vm pool means that no stateless snapshot will be created when a
vm is allocated from the pool, and so vm's disk persist after a user is
done using the vm.
Current implementation is such that this is configurable both on creation
of the pool and later is editable allowing to change a pool from stateless
to stateful and vice versa.
More explanations and possible problems are discussed in the bz above.

I would like to raise a question regarding the behaviour of the pool when
changing the pool from stateless to stateful and from stateful to stateless.

1.
Statless to stateful -> In this case, if all vms are down while the change
occurs then we have no problem at all.
If we have some vms up and allocated to some user - we expect that snapshot
persists and is removed only once the vms are down. Then they go back to the
previous state. And from that point vm is stateful.
If we have prestared vms it's basically the same and we can expect admin to
shutdown the vms in order for the snapshot to be removed.
So this flow might be messy and cause confusion but not that problematic.

2.
Stateful to stateless -> This one is more problematic.
In this case the question raised is, once we changed the pool to stateless,
does that mean that the vm's initial state is the state that was left when
using it as stateful? Or do we re create the vm according to the pool's
template just like we do when changing a pool's template or template
version?
This might cause loss of data which is what the user that requested this
RFE wanted to avoid.

In my personal opinion whether a pool is stateful or stateless sohuld be
determined upon creation and not be changeable, but if that's not the case,
we
have to decide on the wanted behaviour for question 2.

Please share your thoughts on the issue.

Thanks.


-- 
*Sefi   Litmanovich*
RHEV-M           QE
Compute        Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160421/ef87201b/attachment.html>


More information about the Devel mailing list