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. See our section in intense resource usage.

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, LVM block layer
• 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), 206.220.196.57
• power backed by UPS
• Two types of virtualization:
  • qemu-kvm managed by libvirt (full machine virtualization), our recommend choice for most users
  • Linux Containers (LXC) (OS-level virtualization), offered some performance advantages for users running linux guests over full-machine virtualation

Ask for Help! Free migrations available

Don't be afraid to ask for help, email Mark Jenkins <mark@parit.ca> and catch me in person on Tuesdays, hackathons (third Saturdays), special events, and by appointment.

Some free (but not unlimited) migration consulting and assistance is also available.

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).

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. There are performance upsides to using the host OS kernel directly.

There are also downsides, see the Vmsrv_lxc_containers page for more info. You probably want to use our primary virtualization offering, qemu-kvm (see next section)

qemu-kvm with libvirt

Users with accounts on the vmsrv machine are able to run qemu-kvm based virtual machines that are managed by libvirt. We use virt-manager as a libvirt front-end.

Because a fully featured x86/x86_64 machine is emulated and virtualized, a large variety of guest OSs are supported.

virt-manager exposes a large number of features of libvirt and qemu-kvm -- asa GUI app this makes it largely self-documenting. Experiment!

We welcome improvements to this documentation as well.

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. Follow up with Mark Jenkins <mark@parit.ca> to have your account added to the libvirt group.

Accounts are for Skullspace members only.

How to login and start virt-manager

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. virt-manager can be found in the applications menu (bottom left corner) in the System Tools menu, the menu entry says "Virtual Machine Manager".

There's a button on the top, left hand side of virt-manager for creating a new virtual machine.

Memory settings

Your choice of memory setting 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 except by special request to the vm server administrator Mark Jenkins <mark@parit.ca> .

Keep us in the loop as to how often you're using the VM service and what kind of RAM requirements you're hitting -- this will help us justify eventual for an even higher capacity machine.

Network settings

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.

If your guest operating system lacks a proper remote access facility or if your going to end up spending a lot of time doing console access for other reasons, you should look into the feature where a graphic card can be emulated as a vnc server you can directly connect to and also consider the remote access features built-in to the qemu-kvm serial port emulation which can be used as a console on some OSs as well.

virtio

To improve performance, qemu-kvm emulates traditional PC hardware and supports the virtio standard. If you're running a Linux or Windows based guest, we recommend installing the virtio network and disk drivers and uses these options for network and disk in the virt-manager hardware manager so that we can all have better performance.

Always running VMs

VMs created in virt-manager by default will come up on system start-up. There's a checkbox you can check to ensure your VM does come up if required. Please keep the vmsrv administrator (Mark Jenkins <mark@parit.ca>) in the loop as to which VMs you intend to keep up all the time.

Courtesy

If you virtual machine is for experimental/casaual/interactive use and does not need to be on 24/7, please take care to turn it off when you're done. If you notice that allocated RAM is running short, let the server administrator know -- its rude to just shut off someone elses virtual machine -- you can't tell just from looking if its being used or not, especially given the use of remote access.

Services offered to members hosted on vmsrv

The following services being offered to members are hosted on vmsrv:

• MUMD -- a group of linux containers with shared LDAP login and a large install base of interactive software

Coming soon: Skullhost, a shared web hosting service. (not everyone needs to run their own dedicated web server!)

Capital Campaign

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

• IPMI card and remote serial project
• Upgrade to a new combination of motherboard/CPU/RAM (distant goal)

Intense resource usage

As described by in our philosphy section, our priority for the vm server is support members' hacking and not ongoing, high volume "serrious business". The activities of hackers are generally high intensity bursts that are monitored and terminated upon completion, or ongoing low resource services that have minimal impact.

Please respect our sugested memory limits for qemu-kvm/libvirt dedicated VMs. For temporary higher memory use that exceeds these guidelines, we would prefer that you run your processes directly on the host operating system, under your own linux container, or under one of our linux container hosted services (MUMD, Skullhost) as memory effectively allocated (and swapped out) by the host OS kernel for these, whereas dedicated VMs hog whatever memory they're set to use.

You can also get better access to the CPU by running processes on the host OS, your own linux container, or one of our linux container hosted services (MUMD, Skullhost) -- in fact, you're welcome to use all 6 cores. But, you should also be "nice" and use the nice command on your intensive processes:

• "nice -n 1" if your intensive processes is highly interactive (such as raster editor running a filter) and could use your near immediate feedback
• "nice -n 2" if your're looking for your process to finish ASAP, but its the kind of thing where you sit back or take a break while it runs, e.g. http://xkcd.com/303/
• "nice -n 15" if it's the kind of thing that runs so long you're end up working on other things until it's done

As an exception to our focus on "short run intensive, long run unintensive", we do permit our users to operate longer runing processes that are only CPU intensive (not memory or disk access) as long as they're run on the host OS or linux containers, as the kernel can effectively schedule these to be out of the way of everything else with minimal task switching costs. Thanks to modern CPU design, these kinds of processes do raise our electrical bills, so we ask that the number of cores be limited if run times are expected to be longer than one day. Our nice level and number of cores expectation is

• "nice -n 16" and limited to 6 cores if run time less than 2 days
• "nice -n 17" and limited to 3 cores if run time less than 5 days
• "nice -n 18" and limited to 1 core if run time expected is less than 30 days
• "nice -n 19" and limited to 1 core if run time expected to exceed 30 days

Many intensive multi-core programs come with options to control the number of cores in use. If this isn't available, you can use the taskset command, e.g.

• "taskset -c 0 nice -n 19 intensive_monster.py" runs on CPU 0 with nice 19
• "tasket -c 0,1,2 nice -n 17: runs on CPUs 0, 1, and 2 with nice 19

Administrators

• Mark Jenkins <mark@parit.ca>

Thanks

To Kenny for our current 2nd generation equipment, Stef for the first generation equipment, the members of Skullspace for funding the RAM upgrades to the first and second generation servers, and Alex for getting the project started and providing an uninterrupted power supply (UPS).