Friday, February 09, 2007

xen and yoyo

One of the benefits of Xen is that it allows a machine to be easily rebooted. Remote console and remote power management technologies are either expensive or implemented on the motherboards of expensive machines. With Xen the virtual machines can be managed without such expense and also with less effort.

This raises immediate possibilities for training sys-admins. One problem with training system administrators is that they need to have servers to administer and the mentor needs to be able to easily access them and fix them when they become unbootable. Xen makes these problems easy to solve on cheap hardware.

Monash University has for many years had a machine named Yoyo which is used for training sys-admins. It's not expected to be up as much as machines that are run by experienced sys-admins (hence the name) but I expect it would still have better uptime than a lot of corporate servers.

Unfortunately until recently there were no options available to people who weren't Monash students for learning about system administration. To solve this I want to run some sys-admin training with a server.

My plan is to set up a machine running Xen at a server room and provide a basic Debian install in a domU. I will then give the root password to a small group of trustworthy people (who I have known for some time or who are local and can be verified) and start the training. My plan is to set up a mailing list for emergency communication on one of my servers and have the trainees set one up for regular use on the domU. I will provide DNS secondary service and have an NS record for point at the machine in question so the first task for them would be to run a DNS server.

I won't have unlimited bandwidth so I will track the bandwidth use from the dom0, and I will use the dom0 to make backups of the system via LVM snapshots.

The terms of service etc will be mostly copied from the Monash machine.

Please let me know if you have any suggestions for how to run this.

Hopefully this will work out and other people will want to do the same. If you run such a machine then please add a comment to this post with the URL for information on it.


Anonymous said...

Create an initial debootstrapped image, and let all the domUs run
copy-on-write from that image. That way, each individual image will use
minimal disk space. The only resource that poses any limiting factor will
then become RAM, since you need real physical RAM behind the allotments to
each domU. To help with that, I would suggest that you support and encourage
suspending domUs when not in use, to save RAM.

etbe said...

Copy-on-write will give less performance if a large amount of the data differs between images - as I expect to be the case after it's been running for a while and has been upgraded a bit.

Physical RAM is an issue, as I'll be using a P3 desktop machine I will only be able to use 512M of RAM, that means I can run two 128M images and two 96M images - which should be enough for most server tasks.

If I need more than that then I will install a second P3 machine. I've got a bunch of P3 machines hanging around that aren't being used at the moment.