codegen's Journal: The long saga of using Linux to teach an OS Course Part III

The lab for my OS course is moved to a new building that is just being finished. The good news is that the new lab will have updated equipment. I've been using 350 MHz PIIs in the lab running Windows 2000 Pro. The new lab will have 2.4 GHz PIVs runing XP Pro. I'm looking forward to the upgrade. Construction is behind schedule: it is July and the lab is still not finished. We decide to run a test in one of the other labs that is complete.

If I though the first time we ran was a disaster this is even worse. We try and boot 20 VMs from one server and only three come up successfuly. The other 17 corrupt their hard drives. The extra load of booting at 2.4GHz is too much of a strain on the servers. We bring in some other techs to help and after running diagnostics we determine the problem is on the server end. The servers are closing connections because of the load. We spend time looking for some parameter that we can change. To be fair, there probably is some parameter somewhere that we can change, but we don't know what it is, and we can't find it when searching docs and the net. We find a reference to a timeout value in the registry for Windows NT, but changing it in Windows 2000 Pro doesn't seem to make a difference.

One of the techs is managing a Linux server (dual 500Mhz) that is running Samba. It is on the other side of campus (over the campus backbone) and latency may be a problem, but we decide to try it anyways.

Wow!! This is the fastest I have ever seen the lab come up. All virtual machines boot without error. We decide to install Debian on one of the servers to see what happens.

Debian Sarge installs without incident, but we have to download binary drivers for the raid card in the machine. They install without problem. We run the test in the lab and again we have success. Maximum load average while 20 client virtual machines boot is in the mid 7's. After the clients are booted load average drops to less than 0.2 (after all the clients are idle). This is with a straight install and no tweaking!! Non of the clients have any problems with mangling the virtual drives.

I also have to update the version of the kernel being used in the virtual machines. While the 6.2 still works, there were problems last year with students installing at home. It seems that the Redhat installer has problems with PIVs. If an existing image is booted on a PIV, there are no problems. The problems are with the installer itself. This is not surprising since 6.2 predates the PIV.

However, Linux has grown. Mostly the X environment has grown. I still want to keep the image to 500MB if possible to keep the network traffic down. While the lab boots faster with Linux on the server, it still takes time, and the longer the students have to wait, the less time they have in a 2hr lab. I try recent versions of many of the main distributions. The problem is that most of them have compiled the X server with all of the options and bundled most of the clients to gether so that it is impossible to get an install that includes X inside of 500MB. The only mainline distributions that I try that work are Debian Woody and Slackware 10. In both cases, the X window manager is fvwm2, since both KDE and Gnome have long outgrown 500MB. The installations leave about 80 MB free for the students use.

While I like Debian Woody, there is one problem that puts it out of contention. The boot picture is a penguin drinking beer. True, it can be turned off by booting without the framebuffer, but if I am going to distribute it to the students so they can install it at home, the default install will be a problem. My university is a well known international institution, with students from all over the world. There are several religions that take offense at alcohol. My class is a core class, required for the degree program. From a professional and ethical standpoint, this is a problem.

You think we would have learned. While we booted all of the machines at once, (three of us ran around 20 machines starting all of the virtual images), we did not try to transfer files to the main lab file server from more than one machine at a time. The lab does not have a printer. Students work in the lab and then download the files at home to print, or got to a central lab that has a printer. So students ftp from within the virtual machine to the lab server to store the files. In the past there was no problem. However, when installing on the new lab, the techs installed using an option which allows the VM direct access to the host ethernet card. Since we use an imaging process to push the software out to the lab, all of the VMs use the same MAC address for the card.

So they all get the same IP address from the DHCP server. So a single machine can ftp to the main server, but multiple students cannot ftp to the server at the same time. It does not affect the boot since the VM access the HD image file through SMB on the underlying XP OS which uses the ethernets card native MAC (and statically assigned IP address). Switching to NAT mode for the VM solves the problem. There were also some minor problems with the security profile, but all kinks seem the have been worked out.

So now it seems we finally have a functional Linux lab for the OS course. The students write their exam next week and hopefully next year will proceed without technical glitches