As a talking point, how are people going about using virtualisation as a solution here? Are you hosting the VMs on a server or on each individual workstation? Is there an impact on the spec - and price - of said workstations if so (e.g. more RAM)?
We have ours installed on each workstation. There's little to no impact - it's only installed in one ICT suite (likely to expand) but as the suites are built to a certain spec there isn't an issue - the spec includes virtualisation support at hardware level and 4GB ram. The VM's are told to use a single core and 1GB ram so even if we ran these on 2GB machines they're fine.
We help that by keeping the images uses for the VM's very light with NLite type utilities to strip out the nonsense, and only the relevant software installed (the IDE(s), Notepad++ etc ).
Right, so as I suspected this is a solution that works but only if it's been actively worked into the spec based on a planned approach to the problem. Schools that just want to start having pupils creating and running problems willy-nilly without changing/spending anything would need to re-evaluate.
It does sound like the best way of doing it though. Can I ask how you're going about presenting this to the pupils? Is there a way of having seamless integration of virtual apps with the bare metal OS, à la XP Mode?
We didn't spec anything up for it - sensible speccing for any workload just happens to also take care of this. We're not talking massive power or even big storage; 120GB SSD's, 4GB Ram and core i3's is plenty but they run just as happily on older dual core Pentiums.
There's no real integration; we use virtualbox's native ability to "map" a local drive (in this case the N:\ drive, the user's Home folder) into the VM. There's nothing else there, no network, no internet etc which means there's no security issues from users having full admin rights on the VM. Plus as they have immutable drives, once they're restarted, any changes are lost.
We're not using SSDs as standard so that might have something to do with it :P Many schools are still standardising on 2GB RAM. We're trying to move forward with 4GB now.
There is some work going on from a security standpoint as to whether it's possible to "break out" of the virtual sandbox and execute instructions directly on the host. As it stands, there are 17 CPU instructions on the x86 architecture that can't be virtualised. It does seem the risk of this is pretty minimal for now though.
I for one would be interested to hear more. How have you deployed this? Is it part of a standard image?
It's manually copied out at the moment as it's limited to 30 computers. If we need to do more (therefore making the likelihood of rebuilds higher) then it'll just get scripted to copy over via SCCM.
I hasten to add that initial testing on this was on a 2GB Pentium Dual Core (Conroe) machine with a HDD. Thinking about it, I believe the machines we're running them on are HDD. (all new stuff is SSD specified). It runs just as well, the W7 host is happy on 1GB and the guest is allocate 1GB too. Obviously there's overheads involved but as neither hits "the wall" there's no problem.
It's highly unlikely anyone will be using any of the host&guest instruction methods to "break out" of the VM and pose a security threat. If your network setup is solid anyway, that should never be an issue. My best piece of advice currently is not to over-complicate or get overly worried about minor things as it stands
One of our test boxes running ESXi is an old Xeon based HP ML110 - it has absolutely no more power than the old dual core Pentiums, yet it runs 4 VM's perfectly.
Last edited by synaesthesia; 29th September 2013 at 05:46 PM.
Indeed, there shouldn't be any problems there for the time being and that does sound like the best setup. What's the guest OS?
"If your network setup is solid anyway, that should never be an issue. My best piece of advice currently is not to over-complicate or get overly worried about minor things as it stands."
I think I made reference to that earlier.
Absolutely. Guest OS is 7 also. Looked at using XP as it'd be a smaller image, and although it would naturally do the job as intended I felt it was no in the best interests of our students to give them an already long out of date system to play with - it should be current and applicable; for that very same reason it's 64bit too. I wouldn't have wanted to be forced to code everything with the date format DD/MM/YY when I did A-Level computing in the 90's, so the same applies now - I wouldn't expect anyone to be programming with a 32 bit base.
Maybe there could be a way to cram it down into Starter Edition or something to save on space, but other than that it sounds fine.
Quite possible. As said, I used nlite to take out everything unnecessary. Left anything in that may be useful to the users (net framework etc) but removed anything that would otherwise be taking space and resources - games, media players, media centres, admin tools that would serve no purpose, control panel bits that wouldnt ever get used. Probably got it down to around starter levels too, just takes a bit of time to get that initial image setup just right.
There are currently 1 users browsing this thread. (0 members and 1 guests)