Difference between revisions of "Vmsrv"
| Line 21: | Line 21: | ||
===Linux Containers (LXC)=== | ===Linux Containers (LXC)=== | ||
| − | If you want to run a Linux-based x86_64 or x86 based guest, you should consider the | + | 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), which is a newer implementation of [[Operating system-level virtualization wikipedia:Operating_system-level_virtualization]] that is supported upstream. |
| + | (FreeBSD delvelopers are welcome to say "we've had that for ages!") | ||
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. | 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! | |
| + | |||
| + | Avoiding the overhead of full-on virtualization is one advantage, but the largest is that you won't have to pre-define a fixed amount of memory for your container as you would with a true virtual machine, when your processes are busy they enjoy bursts of RAM as allocated by the host kernel, when they're idle they can be individually swapped out. | ||
Revision as of 03:09, 25 May 2012
Philosophy
The Skullspace virtual machine service (vmsrv) is offered to members as a means to share the benifits 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 (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)
- 100Mbit PCI NIC on VOI public IP switch (on host linux bridge skspvoipubbr)
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), which is a newer implementation of Operating system-level virtualization wikipedia:Operating_system-level_virtualization that is supported upstream. (FreeBSD delvelopers are welcome to say "we've had that for ages!")
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!
Avoiding the overhead of full-on virtualization is one advantage, but the largest is that you won't have to pre-define a fixed amount of memory for your container as you would with a true virtual machine, when your processes are busy they enjoy bursts of RAM as allocated by the host kernel, when they're idle they can be individually swapped out.
