Difference between revisions of "Vmsrv"

From SkullSpace Wiki
Jump to navigation Jump to search
Line 17: Line 17:
 
* 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)
 
* 100Mbit PCI NIC on VOI public IP switch (on host linux bridge skspvoipubbr)
 +
 +
Thanks to Stef for the donated equipment.
  
 
==Virtualization Types Available==
 
==Virtualization Types Available==
Line 31: Line 33:
 
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.
 
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.
  
 +
===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. Eventually we would like to make allocation of linux containers on vmsrv possible via libvirt and manageable through nice tools like virt-manager.
 
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)
 
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)
  
(Info for vmsrv admins -- 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)
+
===Info for vmsrv admins===
 +
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===
 
===Virtual Box===
 
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.
 
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 off and nto use the fancy new hardware virtualization those extensions make possible. (But at least we're not doing '''emulation''', Alex found out the hard way how badly that performs!)
+
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.
 +
<br />
 +
But at least we're not doing '''emulation''', Alex found out the hard way how badly that performs!)
  
 
As a result you can only run 32bit x86 guests with a single processor, 64bit and SMP support are not available, as explained in the [https://www.virtualbox.org/manual/ch10.html#hwvirt] Virtual Box technical background:
 
As a result you can only run 32bit x86 guests with a single processor, 64bit and SMP support are not available, as explained in the [https://www.virtualbox.org/manual/ch10.html#hwvirt] Virtual Box technical background:
  
  
==Accounts==
+
===Accounts===
 
Pick one of two ways to get an account:
 
Pick one of two ways to get an account:
 
* Ask the admin team (Mark Jenkins <mark@parit.ca> and Alex Weber)
 
* Ask the admin team (Mark Jenkins <mark@parit.ca> and Alex Weber)

Revision as of 04:28, 25 May 2012

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

As such, we operating a virtual machine service (vmsrv) to support 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

  • Intel Core 2 Quad Q8200 @ 2.33G] with 4M shared L2 cache (does not have VT extensions!)
  • Gigabyte-EP45-UD3L motherboard
  • 2x2G (4G) of DDR2 RAM in dual channel configuration, can upgraded to 4x4G (16G)
  • 4X1TB SATA hard drives in RAID 10 configuration
  • 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
  • 100Mbit PCI NIC on VOI public IP switch (on host linux bridge skspvoipubbr)

Thanks to Stef for the donated equipment.

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

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

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

Info for vmsrv admins

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

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 hardware virtualization possible.
But at least we're not doing emulation, Alex found out the hard way how badly that performs!)

As a result you can only run 32bit x86 guests with a single processor, 64bit and SMP support are not available, as explained in the [1] Virtual Box technical background:


Accounts

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.

Login info

The host vm machine is 192.168.1.26. You can log in with a [[wikipedia:ssh|ssh] client (port 22) or 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) .
(not the usual ports, configure your client! 22 and 3389 are reserved for mumd )