As noted previously, when creating a tutor VM for stage (what's one of those, then?) tutors will need at least one VM to precede theirs, as their new VM must be cloned from an existing one. If no VMs pre-exist on the virtualisation backend, then WLab will not be usable because tutors will not be able to create VMs for labs.
The tutor documentation assumes that a VM exists that contains a basic installation of Windows XP, and nothing else. The example they will work through takes them through authoring a WLab lab exercise using this XP VM as a starting point. Therefore, this XP VM is the very least tutors will need to get started. Realistically, if you are serious about using WLab at your institution, you will probably need to create several VMs depending on the courses WLab will be used for, and the needs of the tutors.
We recommend that you liaise with your tutors at an early point of your WLab endeavours, and take the time up front to set up a suite of “foundation” VMs that the tutors can then build upon. For example, if your tutors are likely to be teaching Java, you might set up a VM that contains the various IDEs your institution uses and a known-good instance of the JDK. If you did not, and instead expected tutors to take the bare bones XP installation, then by themselves install the JDK, then install and set up Eclipse or NetBeans, almost certainly they would run into difficulties. By not making the early effort you will only be creating more support calls for yourself in the future.
You can use the usual Hyper-V management tools to build these VMs. For the most part, VMs that you intend for use by tutors in WLab are no different to any other Hyper-V VM you might create. However, there are several additional factors you will need to consider:
The TightVNC Java applet is used to embed a VM console within WLab-generated web pages. Consequently, all VMs for use with WLab must have a server installed and set to start on boot. If you do not install such a VNC server, the tutor will not be able to connect to the virtual machines through the WLab web interface.
For Windows VMs, it makes most sense to use TightVNC and thus match the VNC flavour being used by the client. TightVNC server – available from http://www.tightvnc.com/ - should be installed within the VM as a service, and the default VNC password for each VM should match that set on the defaultVncPassword parameter in application-settings.xml. Similarly, if you decide to change the VNC port number, you will also need to update the port parameter. These settings MUST be consistent across every VM you intend for use in WLab.
A common mistake is to leave the Windows Firewall on inside your VMs. At the very least, enable traffic on the VNC port you intend to use - 5900 if you have not changed anything. In many cases it may be simpler to disable the Windows Firewall on the backend VMs your tutors will use.
On Linux VMs, there are a multitude of VNC server scenarios, and it is assumed that a system administrator who is au fait with Linux would be able to set up an appropriate solution.
During its lifetime, a tutor VM will be cloned many times – once for each student. In the majority of cases, these clones will be used concurrently (unless it is a one student class!). If from a network perspective the clones are not unique then the students will experience connectivity problems. As noted previously, when a tutor finishes authoring a VM, their last act should be to ensure that, upon the first boot of any clone, the clone makes itself unique.
If you are using DHCP, this should not be an issue in terms of IP addressing. However, on Windows workstations there is also the computer name to consider – computer names must be unique. Some kind of script is therefore required that will change the computer name of a newly cloned VM to a unique (random) value. In the tutor documentation this is referred to as “making the VM safe” and it is stressed upon them that this must always be the last task they perform in a tutor VM before they attempt to publish it in a lab stage.
TUTORS WILL EXPECT YOU TO PROVIDE THEM WITH DOCUMENTATION AS TO HOW THEY SHOULD PERFORM THIS TASK.
The recommended Microsoft method of achieving this is by using Sysprep; however, this takes far too long to complete for it to be usable in WLab. When a student accesses the next stage of a lab exercise it is not acceptable to subject them to a 10 minute delay while Sysprep executes.
The best results have been achieved using Dave Clarke’s wsname script, which can be found at the URL http://mystuff.clarke.co.nz/MyStuff/wsname.asp. The following is one method of using wsname to provide a facility for making a VM safe:
This configuration means that all a tutor needs to do to make a VM safe is to copy c:\wsname\rename.old to c:\wsname\rename.bat as their last action before they close the VM down. Any clones that are made after this point will start up, find the script in c:\wsname and execute the script.
A sample set of instructions for tutors to use this script might be as follows:
Tutor addendum – Making your Tutor VMs safe
It is very important that, when you have finished configuring a tutor VM for stage, you make it safe for use by a student.
To do so, follow these steps:
Your tutor VM for stage has now been made safe. You should now immediately shut it down, and it can now be used in a lab stage.
Note that a student will be provided with the same environment as the tutor. You might be tempted to create a batch file that performs these tasks, place it on the VM desktop, and tell tutors “to make your VMs safe, click the icon on the desktop”. However, such a desktop icon would also be visible by students when they run their lab exercises. There is obviously a high risk that students will - even if told NOT to - try clicking the forbidden yet ever-so-inviting icon! You should weigh up the convenience for your tutors against the risk of creating support headaches from the student body.
Here is a detailed breakdown of the steps in the script:
@echo off Suppresses output to the console.
c:\wsname\wsname /n:WLAB-$RANDOM[10] Uses wsname to change the computer name to WLAB-[a 10 character random string]
shutdown –s –f –t 1 Issues the command to shut down the virtual machine in one second’s time – changes to the computer name only take effect after a reboot.
del c:\wsname\rename.bat Delete the script so it is not executed on subsequent reboots.
If you do not wish to use this technique, you should note that WLab assumes that when a tutor VM is cloned in order to create a new VM for a student, the following will occur:
The point in bold is crucial, and you need to make sure that your alternative method of changing the computer name shuts the VM down completely at this point, rather than just issuing a restart. Also, if you use an alternative method of “making safe” bear in mind you will also need to provide the tutors with documentation for it. The tutor documentation explicitly mentions that you will provide them with such instructions, and advises them not to attempt to use the system if they do not have them, or do not understand them.
There may be instances where the “making safe” procedure is not necessary. If a tutor is designing a VM that has no need for Microsoft networking connectivity you could remove the Microsoft networking components (you would still need TCP/IP in order to establish a VNC connection), and there would be no need for the “making safe” procedure. Similarly, this would probably not be required on most Linux configurations (assuming that DHCP was being used and SAMBA was not). If, for some reason, a VM does not require the “making safe” procedure, the tutor should be advised to change the default setting for Boot cycles after cloning from 2 to 1 when they configure their VMs. Details of where to find this setting are in their documentation.
When WLab creates a new virtual machine, it will use one of two suffixes:
| BASE- | a tutor VM | |
| DYNAMIC- | created by the system for use by a student, cloned from a tutor VM |
Do not delete any such virtual machines via Hyper-V’s own management tools. This may cause errors in WLab.