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(a)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(a)redhat.com
RHEV-CI Team