Vmsrv

Philosophy

The Skullspace virtual machine service (vmsrv) is offered to members as a means to share the benefits of best-available hardware.

"Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total."

We focus our virtual machine service on two styles of computing

• Interactive computing -- temporary bursts of high resource use (IO/CPU/memory) by a single user for the purpose of "figuring stuff out", "getting stuff done", "hacking", etc. with the ethic of ensuring resources are freed when not in use. "Always yield to the Hands-On Imperative!"
• General service computing -- always up and running services with reasonable IO, CPU, and memory use that doesn't impair the above.

(services with intense all the time resource requirements should be operated on dedicated servers)

System

• AMD Phenom II X6 1055T, which has 6 core, 512k L2 cache per core, a shared 6M L3 cache, and AMD's virtualization extensions
• Asus M5A88-V EVO motherboard
• 4x4G (16G total) of DDR3 RAM in unganged mode, 1333.33 MT/s configuration,
• 4X1TB SATA hard drives in RAID 10 configuration
• Debian GNU/Linux 6.0 amd64 host operating system
• 1GBit internal NIC on SkullSpace lan (on host Linux bridge skspprivbr), 192.168.1.26
• 100Mbit PCI NIC on VOI public IP switch (on host Linux bridge skspvoipubbr)
• Virtualization using Linux Containers (LXC) and VirtualBox 4.0

Linux Containers (LXC)

If you want to run a Linux-based x86_64 or x86 based guest, you should consider the benefits of running it as a Linux Container (LXC). These are a newer implementation of OS-level virtualization that is supported upstream.
(FreeBSD fans like Mak and Dave are permitted to gleefully says "we've had that for ages, what took you so long Linux!?")

The main vmsrv kernel (version 2.6.32) directly runs your processes (starting with /sbin/init!) in an independent process space and gives you your own network stack (interfaces, routing tables, iptables) to work with.

Kick-ass performance for your kick-ass userland

Beyond that, leave the kernel to us and focus on rocking your userland! Pretty much any GNU/Linux distro can be booted this way. (some tweaking sometimes needed)

Avoiding the overhead of full-on virtualization and that kernel-hypervisor relationship is an obvious advantage, but even more important is that you won't have to pre-define and hog a fixed amount of memory for your container as you would with a full virtual machine (like VirtualBox, see next section). When your processes are busy they can enjoy bursts of RAM as allocated by the host kernel, when they're idle they can be individually swapped out.

And you get to use all 4 cores. :)

Get your container today

To get your own container, contact Mark Jenkins <mark@parit.ca>. A fresh container with a minimal install can be built and handed over or an existing file system converted.

See the section on libvirt for more on our hopes to make direct-user allocation possible.

You can also enjoy the benefits of Linux containers without having to administer your own by signing up for an account on mumd -- a cluster of Linux containers with common LDAP login hosted on vmsrv. (Read more on the mumd page)

Virtual Box

Users with accounts on the vmsrv machine are able to run Virtual Box 4.0. There are many supported guest operating systems, and that support is at its best with guests where you can install "virtual box guest additions" which are extra drivers and things that make the guest work better with the host.

Because our CPU doesn't have VT extensions Virtual Box is only able to do a slower "software" virtualization with some insane trickery. A CPU with VT extensions would make hardware virtualization possible.

As a result you can only run 32bit x86 guests with a single processor, 64bit and SMP support are not available. This is explained in way more detail than you can handle in the Virtual Box technical background

Accounts

Pick one of two ways to get an account:

• Ask the admin team (Mark Jenkins <mark@parit.ca>)
• Use the automated claimid process for mumd at http://192.168.1.28 . mumd accounts are made available to the vmsrv host system via the wonders (and down sides) of LDAP.

Accounts are for Skullspace members only.

How to login and start VirtualBox

The host vm machine is 192.168.1.26 on the skullspace LAN. Three ways to log in the from the Skullspace network:

• A SSH client (port 22), for graphics use -X or port forward a vnc session
• RDP client (port 3389)
• XDMCP, e.g. X -query 192.168.1.26, Xephyr -query 192.168.1.26, Xnest -query 192.168.1.26

From outside the space, there are two options:

• SSH to vmsrv.markjenkins.ca (206.220.196.57 port 22 )
• RDP client to vmsrv.markjenkins.ca (206.220.196.57 port 3389)

The default desktop environment is LXDE which is fairly lightweight, but still least has a menu in the corner and a task bar. VirtualBox can be found under the accessories menu under the main application launch menu in the bottom left corner.

Documentation

The features of Virtual Box are well documented

Memory settings

The memory setting in virtual box is very important. Feel free to be more on the greedy side (3 gigabyte) if you're just starting your vm, doing your thing, and shutting it down when you're done (interactive use).

If you're planning on running all the time, than you should use 1G at most.

Let everyone know how often you're using the VM service and what kind of RAM requirements you're hitting -- this will help us justify an upgrade to maximum RAM and eventually start fundraising for an even higher capacity machine.

Sound setting

Disable the virtual sound card, sound isn't available (right now)

Network settings

We recommend using the bridged adapter instead of NAT. Join the skspprivbr bridge for the skullspace network and the skspvoipubbr bridge if you have a VOI public ip addresses allocated to you on the networking page.

Remote Access

We recommend installing guest operating systems with remote access features that are either built in or installable and enabling these features shortly after completing your install.

This will allow you to go for direct logins to your virtual machine. You should also look into the commands for starting up VirtualBox "headless" -- once your vm is set up nicely you can probably do much faster starts and stops of it via ssh commands.

VirtualBox also has a feature for remote access to its virtual console, but this requires a guest system with VirtualBox guest extensions.

Always running VMs

The commands for starting and stopping VirtualBox "headless" will also be useful for smaller virtual machines that folks will be keeping online all the time. You could technically use cron to do this for yourself, but its also fine if you ask the admins to set this up.

Eventually we'd like to manage these kinds of VMs through libvirt. (see below)

libvirt

Eventually we would like to make allocation of linux containers and management of headless VirtualBox systems ime possible via libvirt and manageable through nice tools like virt-manager.

libvirt has support for both of them, but we have to learn how to use it. virt-manager has some support but not for creating the configs for these two to beging with, but it does respond to command line arguments related to lxc and VirtualBox... and probably is okay once the underlying config files are in place it lets you manage the turning on and off...

If we manage to upgrade the CPU to one that does have VT extensions, we'll have the possibility of replacing virtualbox with KVM and qumu which has better support under virt-manager.

Capital Campaign

The vmsrv project is raising money for upgrades. Projects goals in order of priority are:

• IMPI card
• Upgrade to a new combination of motherboard/CPU/RAM (distant goal)

Administrators

• Mark Jenkins <mark@parit.ca>

Thanks

To Kenny for our current 2nd generation equipment, Stef for donating the first generation equipment and Alex for getting the project started.