Difference between revisions of "Vmsrv"

From SkullSpace Wiki
Jump to navigation Jump to search
m (update mobo link)
(42 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.33G]] 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 block 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 and Virtual Box 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.
+
 
 +
==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)==
 
==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
+
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).  
[[wikipedia:Operating_system-level_virtualization|OS-level virtualization]] that is supported upstream.
+
 
<br />
+
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.
(FreeBSD fans like Mak and Dave are permitted to gleefully says "we've had that for ages, what took you so long Linux!?")
+
 
 +
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)
  
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.
+
==qemu-kvm with libvirt==
 +
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.
  
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)
+
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.
  
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 true virtual machine (like virtual box). 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.
+
virt-manager exposes a large number of features of libvirt and qemu-kvm -- asa GUI app this makes it largely self-documenting. Experiment!
  
===Get your container today===
+
We welcome improvements to this documentation as well.
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. Eventually we would like to make allocation of linux containers on vmsrv possible via libvirt and manageable through nice tools like virt-manager.
 
  
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)
+
===Accounts===
 +
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:
 +
* 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>.
  
===Info for vmsrv admins===
+
Accounts are for Skullspace members only.
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 configs)
 
  
==Virtual Box==
+
===How to login and start virt-manager===
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.
+
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:Secure_Shell| SSH]] client (port 22), for graphics use -X or port forward a vnc session
 +
* [[wikipedia:RDP | RDP]] client (port 3389)
  
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.
+
From outside the space, there are two options:
<br />
+
* [[wikipedia:Secure_Shell|SSH]] to vmsrv.skullspace.ca (206.220.196.57 port 22 )
But at least we're not doing '''emulation''', Alex found out the hard way how badly that performs!)
+
* [[wikipedia:RDP | RDP]] client to vmsrv.skullspace.ca (206.220.196.57 port 3389)
  
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]
+
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".
  
===Accounts===
+
There's a button on the top, left hand side of virt-manager for creating a new virtual machine.
Pick one of two ways to get an account:
 
* Ask the admin team (Mark Jenkins <mark@parit.ca> and Alex Weber)
 
* 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.
+
===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).
  
===How to login and start VirtualBox===
+
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> .
The host vm machine is 192.168.1.26. You can log in with a [[wikipedia:ssh|ssh] client (port 22) or [[wikipedia:RDP | RDP]] client (port 3389) if you're at the space. From the the space, ssh access is available on port 2222 and RDP on port 23389 courtesy of the Skullspace router (skullspace.markjenkins.ca,  206.220.196.50) .
 
<br />
 
(not the usual ports, configure your client! 22 and 3389 are reserved for [[mumd]] )
 
  
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.
+
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.
  
===Settings===
+
===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 [[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.
 +
 +
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 [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===
 +
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
 +
 +
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).
 +
 +
[[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