Using VM Pools enables to use only stateless virtual machines. There is no options for users to save non-volatile data as well for upgrade system, install or update software.
vm-pools are stateless by definition, making it statefull collides with the concept the vm is part of a pool and can be used by different users every time. did you try to use 'manual' vm-pool? i think this can fit your use case: in manual vm-pools, user take vm from pool, and the user owns the vm until manually removed by the administrator, the state of the vm is kept even if the vm is stopped, until this manual operation (admin need to remove the user permission from the specific vm). once the admin removes the user permission from the vm, the state is cleared and the vm is returned to the pool. this option available under "Type" tab in the new vm-pool dialog. please update if this works for you.
ping?
Sorry for the late reply, it's been vacation time around here. Our Windows VDI template does not contain any data, just the VM config and an empty disk. When we deploy the pool, all the pool VM's disks are initially empty and they are all PXE booted off the SCCM server to install Windows in each individual pool VM. We have tried the manual pool. Even installing these Windows machines in a manual pool failed. All the task sequences in SCCM did not complete for some reason. However using the same VM template for deploying a normal (non-pool) VM works just fine. Never the less, there is personal data stored in the VM which should never be deleted, even if the machine is released from the user (users permission to the machine is removed). This is company policy. Our RHEL VDI's on the other hand, are using (stateless) automatic pools, and for this use case stateless VM's are working just fine. If we did manage to get a manual stateless pool for the Windows VDI's working, it would make the machine unusable when the machine was released, as the computer password would have been changed, the central database detailing installed software and patches would be out of sync. And the list goes on over system software that does not support reverting to a previous snapshot without further manual intervention. Human error may also happen, where the helpdesk personnel may release (remove the permissions from) the incorrect user at the incorrect pool VM. This will cause this user to experience a data loss. A side note: I'm sure we all agree that personal data should never be stored on the local OS disk, however in a Windows environment that is virtually impossible to achieve. Please consider making stateless VM's an option in a pool, not a requirement as it is today.
OK, seems to be a good justification. The feature will be: - it will be possible to decide to create a stateful pool (new pool dialog/REST API) and also to change the pool from stateful to stateless (edit pool dialog/REST) - the pool will still be a set of VMs with homogeneous HW - only the content of the disks will be different
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Verified with rhevm-4.0.0.6-0.1.el7ev.noarch according to test plan. See test run results: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=4_0_VIRT_Stateful_Vm_Pools_07062016
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-1743.html