What you need to know up front as a potential WLab SysAdmin

Assumptions

This documentation is intended for those who will have the responsibility of installing and configuring the WLab software, and who will then be responsible for providing support to tutors. The following is assumed on the part of the system administrator:

• They are familiar with the concept of virtualisation and virtual machines
• They have experience of managing a virtualisation solution at the backend, such as VMWare or Hyper-V
• They have experience of managing web server solutions, and know how to perform basic administration tasks (e.g. stop, start) on a web server.
• They understand the implications of making changes to an institutional firewall, and are either capable of making such changes themselves or arranging for someone else to make them
• They are comfortable working at a command line level and editing configuration files.

This documentation will also be useful to developers who wish to make changes to the WLab software, as they will need to know how to configure a new installation.

It is very important that any potential system administrator of a WLab system reads, understands and is aware of the implications raised by this document, and by the manner in which WLab operates. This will prevent inevitable support woes further down the line!

How WLab operates

From a system administrator’s point of view, the most important thing to know is that WLab will dynamically create clones of virtual machines as and when they are required. When a tutor designs a lab exercise, they will make a clone of an existing virtual machine, and then modify it to suit the needs of the lab. This modified clone is then referred to as a Tutor VM (check out The difference between a backend VM and a tutor VM).

When a student connects to a lab, WLab will automatically create a copy of any tutor VMs the lab may contain, exclusively for that student’s use. This means that, depending on class sizes, WLab may create dozens or even hundreds of virtual machines for a given lab exercise. However, these VMs use differential disks, so should not take up great amounts of disk space. More discussion of such considerations takes place in System Requirements.

Responsibilities of a WLab system administrator

Above and beyond the normal requirements for administering a web-based application, administering a WLab system comes with a number of other responsibilities.

• For the WLab application to be useful there must be at least one backend VM available to tutors to clone in the very first instance – otherwise they will not be able to author their VMs. The system administrator will need to author useful VMs, and configure them accordingly. This is discussed in more detail later.
  
  
• If one were to clone a virtual machine several times, and then start up all the clones simultaneously issues would almost certainly arise because they would have identical network configurations. On Windows VMs in particular, running several machines with the same computer name can mean that none of them will be able to access the network properly.
  
  Consequently, the last activity a tutor undertakes when finalising a VM is to make sure that, on the next reboot, the Windows computer name is made unique. In the tutor documentation this is referred to “making the VM safe” and tutors will expect you to provide instructions on how they can achieve this. The procedure will vary, depending on the approach you choose. Further discussion on this subject and exemplar instructions “making VMs safe” for tutors can be found in Dealing with WLab virtual machines.

If none of this has prompted you to assault the tutor who first said "hey, this WLab thing looks good" with an iron girder, then you probably want to go on and check out the System Requirements.