Difference between revisions of "Vmsrv"

From SkullSpace Wiki
Jump to navigation Jump to search
m (update mobo link)
(30 intermediate revisions by 2 users not shown)
Line 6: Line 6:
 
We focus our virtual machine service on two styles of computing
 
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!"
 
* 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.
+
* 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.
<br />
 
(services with intense all the time resource requirements should be operated on dedicated servers)
 
  
 
==System==
 
==System==
* [http://ark.intel.com/products/36547 Intel Core 2 Quad Q8200 @ 2.33Ghz]] with 4M shared L2 cache (does not have VT extensions!)
+
* [http://www.amd.com/us/products/desktop/processors/phenom-ii/Pages/phenom-ii-model-number-comparison.aspx AMD Phenom II X6 1055T], which has 6 core, 512k L2 cache per core, a shared 6M L3 cache, and AMD's virtualization extensions
* [http://www.hardwaresecrets.com/article/Gigabyte-EP45-UD3L-Motherboard/705/1 Gigabyte-EP45-UD3L motherboard]
+
* [https://www.asus.com/ca-en/Motherboards/M5A88V_EVO/specifications/ Asus M5A88-V EVO] motherboard
* 2x2G (4G) of DDR2 RAM in dual channel configuration, can upgraded to 4x4G (16G)
+
* 4x4G (16G total) of DDR3 RAM in unganged mode, 1333.33 MT/s configuration,  
* 4X1TB SATA hard drives in RAID 10 configuration
+
* 2X1TB SATA hard drives in RAID 1 configuration, [[wikipedia:Logical_Volume_Manager_%28Linux%29LVM|LVM]] block layer
 
* Debian GNU/Linux 6.0 amd64 host operating system
 
* Debian GNU/Linux 6.0 amd64 host operating system
* LVM bock layer, RAID10 is the sole physical volume for the sole volume group (vmsrv). Logical volumes to be created and extended from this volume group as needed
+
* 1GBit internal NIC on SkullSpace lan (on host Linux bridge skspprivbr), 192.168.1.26
* 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
* 100Mbit PCI NIC on VOI public IP switch (on host linux bridge skspvoipubbr)
+
* power backed by UPS
* Virtualization using Linux Containers (LXC) and VirtualBox 4.0
+
* Two types of virtualization:
 +
** qemu-kvm managed by libvirt (full machine virtualization), our recommend choice for most users
 +
** Linux Containers (LXC) ([[wikipedia:Operating_system-level_virtualization|OS-level virtualization]]), offered some performance advantages for users running linux guests over full-machine virtualation
  
Thanks to Stef for the donated equipment.
 
  
==Linux Containers (LXC)==
+
==Ask for Help! Free migrations available==
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
+
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.
[[wikipedia:Operating_system-level_virtualization|OS-level virtualization]] that is supported upstream.
 
<br />
 
(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.
+
Some free (but not unlimited) migration consulting and assistance is also available.
  
===Kick-ass performance for your kick-ass userland===
+
==Linux Containers (LXC)==
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)
+
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).  
 
 
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 allocation of Linux containers not require dealing with a [[wikipedia:BOFH | BOFH].
+
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.
  
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)
+
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)
  
===Info for vmsrv admins===
+
==qemu-kvm with libvirt==
The linux containers are kept in /var/lib/lxc and started up by /etc/init.d/lxc . /etc/lxc and /etc/default/lxc are also relevant config dirs and files)
+
Users with accounts on the vmsrv machine are able to run qemu-[http://www.linux-kvm.org/page/Main_Page kvm] based virtual machines that are managed by [http://libvirt.org/ libvirt]. We use [http://virt-manager.org/ virt-manager] as a libvirt front-end.
  
==Virtual Box==
+
Because a fully featured x86/x86_64 machine is emulated and virtualized, a large variety of [http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_BSD guest OSs] are supported.
Users with accounts on the vmsrv machine are able to run [http://www.virtualbox.org/ Virtual Box 4.0]. There are many supported [https://www.virtualbox.org/wiki/Guest_OSes 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 hardware virtualization possible.
+
virt-manager exposes a large number of features of libvirt and qemu-kvm -- asa GUI app this makes it largely self-documenting. Experiment!
  
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 [https://www.virtualbox.org/manual/ch10.html#hwvirt Virtual Box technical background]
+
We welcome improvements to this documentation as well.
  
 
===Accounts===
 
===Accounts===
Pick one of two ways to get an account:
+
To get an account, visit the account claiming page, [http://claimid.vmsrv.skullspace.ca http://claimid.vmsrv.skullspace.ca] from the Skullspace LAN (not available from the outside). At that page, there are two options:
* Ask the admin team (Mark Jenkins <mark@parit.ca> and Alex Weber)
+
* Claiming a regular vmsrv account, which will work right away.
* 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.
+
* Claim an account on [[mumd]], which thanks to LDAP can also be used to log into vmsrv. But, such an account has to be manually added to the libvirt group, so you'll have to contact Mark Jenkins <mark@parit.ca>.
  
 
Accounts are for Skullspace members only.
 
Accounts are for Skullspace members only.
  
===How to login and start VirtualBox===
+
===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:
+
The host vm machine is 172.30.6.40 on the skullspace LAN. Two ways to log in the from the Skullspace network:
* A [[wikipedia:ssh | ssh] client (port 22), for graphics use -X or port forward a vnc session
+
* A [[wikipedia:Secure_Shell| SSH]] client (port 22), for graphics use -X or port forward a vnc session
 
* [[wikipedia:RDP | RDP]] client (port 3389)
 
* [[wikipedia:RDP | RDP]] client (port 3389)
* [[wikipedia:XDMCP | XDMCP]], e.g. X -query 192.168.1.26, Xephyr -query 192.168.1.26, Xnext -query 192.168.1.26
 
  
 
From outside the space, there are two options:
 
From outside the space, there are two options:
* [[wikipedia:ssh | ssh] to skullspace.markjenkins.ca port '''2222''' (22 is used by [[mumd]]
+
* [[wikipedia:Secure_Shell|SSH]] to vmsrv.skullspace.ca (206.220.196.57 port 22 )
* [[wikipedia:RDP | RDP]] client to skullspace.markjenkins.ca port '''23389''' (3389 is used by [[mumd]]
+
* [[wikipedia:RDP | RDP]] client to vmsrv.skullspace.ca (206.220.196.57 port 3389)
 +
 
 +
The default desktop environment is [[wikipedia:LXDE | 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".
  
The default desktop environment is []wikipedia:LXDE | 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.
+
There's a button on the top, left hand side of virt-manager for creating a new virtual machine.
  
 
===Memory settings===
 
===Memory settings===
The memory setting in virtual box is very important. Feel free to be more on the greedy side (1 gigabyte) if you're just starting your vm, doing your thing, and shutting it down when you're done (interactive use).
+
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 need to be more on the low side like 256 megabytes. Keep in mind that any page swapping your guest operating system sends to your virtual "disks" is able to benefit from the host operating system allocated memory not used by programs to disk caching, so a little paging sometimes won't be that bad,,,. (a lot of paging, called '''thrashing''' most certainly will be)
 
  
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.
+
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> .
  
===Sound setting===
+
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.
Disable the virtual sound card, sound isn't available (right now)
 
  
 
===Network settings===
 
===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 [[Networking |on the networking page].
+
Join the skspprivbr bridge for the skullspace network and the skspvoipubbr bridge if you have a VOI public ip addresses allocated to you [[Networking |on the networking page]].
  
 
===Remote Access===
 
===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.
 
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.
+
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.
  
VirtualBox also has a feature for remote access to its virtual console, but this requires a guest system with VirtualBox guest extensions.
+
===virtio===
 +
To improve performance, qemu-kvm emulates traditional PC hardware and supports the [http://wiki.libvirt.org/page/Virtio 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===
 
===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.
+
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:
 +
* [[shell.skull.space]] -- Newer shell account service
 +
* [[Mumd|MUMD]]  -- Our old shell account service
 +
* [[Skullhost]], a shared web hosting service. (not everyone needs to run their own dedicated web server!)
 +
* [[skullmail]], mail relay to assist you in running a home email server, messages are not stored here
 +
 
 +
==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
  
Eventually we'd like to manage these kinds of VMs through libvirt. (see below)
+
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
  
==libvirt==
+
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.
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.
+
* "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 17
  
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...
 
  
 
==Administrators==
 
==Administrators==
 
* Mark Jenkins <mark@parit.ca>
 
* Mark Jenkins <mark@parit.ca>
* Alex Weber
+
* Alex Weber <alexwebr@gmail.com> (I'm new still)
 +
 
 +
==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).
 +
 
 +
[[Category:Projects]]
 +
<nowiki>Insert non-formatted text here</nowiki>

Revision as of 23:50, 14 April 2019

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,
  • 2X1TB SATA hard drives in RAID 1 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

To get an account, visit the account claiming page, http://claimid.vmsrv.skullspace.ca from the Skullspace LAN (not available from the outside). At that page, there are two options:

  • Claiming a regular vmsrv account, which will work right away.
  • Claim an account on mumd, which thanks to LDAP can also be used to log into vmsrv. But, such an account has to be manually added to the libvirt group, so you'll have to contact Mark Jenkins <mark@parit.ca>.

Accounts are for Skullspace members only.

How to login and start virt-manager

The host vm machine is 172.30.6.40 on the skullspace LAN. Two 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)

From outside the space, there are two options:

  • SSH to vmsrv.skullspace.ca (206.220.196.57 port 22 )
  • RDP client to vmsrv.skullspace.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:

  • shell.skull.space -- Newer shell account service
  • MUMD -- Our old shell account service
  • Skullhost, a shared web hosting service. (not everyone needs to run their own dedicated web server!)
  • skullmail, mail relay to assist you in running a home email server, messages are not stored here

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 17


Administrators

  • Mark Jenkins <mark@parit.ca>
  • Alex Weber <alexwebr@gmail.com> (I'm new still)

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). Insert non-formatted text here