Thanks a lot for the welcome and suggestion! 

I brought your suggestion up with my tutor and was informed VM pooling is something which has been discussed and considered internally and at this juncture it has been decided that pooling is an optimisation which is going to be implemented at a later date. At this time the system is going to be used  

Makes sense from a performance perspective in an enterprise because you'd have separate storage server + all the images / software would likely be pre-loaded with the same bits of software. 

This is not always going to be the case with us as we've got a lot of different images with varied installations, we've got students from different year groups using different images at the same time. Also we want the students to have the freedom to install their own tools / software.

The primary motivation for using oVirt at our university is to enable the students remote access to a lab environment. Although I mentioned in my previous mail that we wanted students to be able to quickly spin up VMs, I should have used the word simply, as it's more a case of minimising distractions + amount of actions required to create a VM from template.
 
Unfortunately at this juncture we do not have the resources available to set up VM pooling for all of the different images we make use of so are going to approach the workflow in terms of students creating the VMs from template.

Many Thanks,
Thomas

On 12 January 2016 at 09:02, Barak Korren <bkorren@redhat.com> wrote:
Hi,

Thanks for getting involved with oVirt!
>
> 1) The ability to quickly create a new VM from a template, whilst hiding
> some of the complexity from the user.
>
It seems to me you can gain the same simplicity benefits by using VM
pools and with no additional code...
While cloud environments have made people used to dynamically spinning
up VMs, this is a hammer that does not fit all nails, a pool of
stateless pre-created VMs might suit your need better, and will work
faster from an individual user's point of view.
It is also more efficient in storage terms.

>
> 2) The ability to provide some of the more advanced features whilst hiding
> some of the complexities of the Extended view
> ...
>
> Proposed Solution A: Create a third tab ...
>
> Proposed Solution B: Similar to the above ...
>
> Proposed Solution C: Add settings that will allow the user to enable/disable
> GUI elements in the userportal as required.
>
I would go with solution C which seems to me the most generally useful...

>
> 3) Ability to specify sets of VM templates which can be created as new VMs
> together
>
In conjunction with my proposal for feature 1, think about how this
would work for pools...

--
Barak Korren
bkorren@redhat.com
RHEV-CI Team