Vmsrv - Revision history

Markjenkinsparit: Revised equipment thanks

2019-05-24T14:39:24Z

Revised equipment thanks

Markjenkinsparit: /* Services offered to members hosted on vmsrv */

2019-05-23T14:58:12Z

‎Services offered to members hosted on vmsrv

Markjenkinsparit: cleanup lots of out of date stuff

2019-05-23T14:57:48Z

cleanup lots of out of date stuff

Markjenkinsparit: vmsrv host keys

2019-05-21T13:12:29Z

vmsrv host keys

Markjenkinsparit: whonix.skull.space is now offered

2019-05-21T03:05:27Z

whonix.skull.space is now offered

Markjenkinsparit: clarify existing vmsrv services

2019-05-21T03:03:29Z

clarify existing vmsrv services

Markjenkinsparit: /* Linux Containers (LXC) ask mark */

2019-05-21T03:00:16Z

‎Linux Containers (LXC) ask mark

Markjenkinsparit: More rollout for unprivileged Linux Containers (LXC)

2019-05-21T02:59:36Z

More rollout for unprivileged Linux Containers (LXC)

Markjenkinsparit: skullspace 2.0 lan address long ago replaced skullspace 1.0 address

2019-05-21T02:56:50Z

skullspace 2.0 lan address long ago replaced skullspace 1.0 address

Markjenkinsparit: unprivileged lxc containers now available, preferred

2019-05-21T02:54:56Z

unprivileged lxc containers now available, preferred

@@ Line 121: / Line 121: @@
 * Alex Weber <alexwebr@gmail.com> (I'm new still)
-==Thanks==
+==Equipment Donation 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).
+* Stef for the first motherboard, case, power supply and hard drives (1 of these drives still in use)
 ==SSH host keys==

@@ Line 90: / Line 90: @@
 * [[shell.skull.space]] -- Newer shell account service
 * [[Skullhost]], a shared web hosting service. (not everyone needs to run their own dedicated web server!)
 * [[whonix.skull.space]], conveniently access a Whonix gateway via ssh
 * [[mail.skull.space]], an inbound mail relay to assist you in running a home email server. (please don't use for state department business)

@@ Line 39: / Line 39: @@
 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.
-virt-manager exposes a large number of features of libvirt and qemu-kvm -- asa GUI app this makes it largely self-documenting. Experiment!
+virt-manager exposes a large number of features of libvirt and qemu-kvm -- as a 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 http://claimid.vmsrv.skullspace.ca] from the Skullspace LAN (not available from the outside). At that page, there are two options:
+To get an account, 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:
+The host vm machine is 172.30.6.40 on the skullspace LAN. 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
-From outside the space, there are two options:
-* [[wikipedia:Secure_Shell|SSH]] to vmsrv.skullspace.ca (206.220.196.57 port 22 )
+From outside the space:
-* [[wikipedia:RDP | RDP]] client to vmsrv.skullspace.ca (206.220.196.57 port 3389)
+* [[wikipedia:Secure_Shell|SSH]] to vmsrv.skullspace.ca (208.81.6.230 port 22 )
 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".

@@ Line 126: / Line 126: @@
 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>

@@ Line 93: / Line 93: @@
 * [[shell.skull.space]] -- Newer shell account service
 * [[Skullhost]], a shared web hosting service. (not everyone needs to run their own dedicated web server!)
 * [[mail.skull.space]], an inbound mail relay to assist you in running a home email server. (please don't use for state department business)
 ** (currently used to inbound relay @markjenkins.ca)

@@ Line 92: / Line 92: @@
 The following services being offered to members are hosted on vmsrv:
 * [[shell.skull.space]] -- Newer 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
+* [[mail.skull.space]], an inbound mail relay to assist you in running a home email server. (please don't use for state department business)
 ==Intense resource usage==

← Older revision		Revision as of 03:00, 21 May 2019
Line 31:		Line 31:

	The main vmsrv kernel directly runs your processes, all under your own user account (starting with /sbin/init!) in an independent process space and gives you your own network stack (interfaces, routing tables, iptables) to work with. You have root in the container even though its not root on the host system. (achieved with process id mapping) There are performance upsides to using the host OS kernel directly and this reduces the RAM usage overall.		The main vmsrv kernel directly runs your processes, all under your own user account (starting with /sbin/init!) in an independent process space and gives you your own network stack (interfaces, routing tables, iptables) to work with. You have root in the container even though its not root on the host system. (achieved with process id mapping) There are performance upsides to using the host OS kernel directly and this reduces the RAM usage overall.
		+
		+	Ask Mark Jenkins <mark@parit.ca> to set your account up for this

	==qemu-kvm with libvirt==		==qemu-kvm with libvirt==

@@ Line 28: / Line 28: @@
 ==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).
+If you want to run a Linux-based x86_64 or x86 based guest, you should consider the benefits of running it as an unprivileged 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.
+The main vmsrv kernel directly runs your processes, all under your own user account (starting with /sbin/init!) in an independent process space and gives you your own network stack (interfaces, routing tables, iptables) to work with.  You have root in the container even though its not root on the host system. (achieved with process id mapping) There are performance upsides to using the host OS kernel directly and this reduces the RAM usage overall.
 ==qemu-kvm with libvirt==

@@ Line 14: / Line 14: @@
 * 2X1TB SATA hard drives in RAID 1 configuration, [[wikipedia:Logical_Volume_Manager_%28Linux%29LVM|LVM]] block layer
 * Debian GNU/Linux 9 amd64 host operating system
-* 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), 172.30.6.40
 * 100Mbit PCI NIC on VOI public IP switch (on host Linux bridge skspvoipubbr), 206.220.196.57
 * power backed by UPS

@@ Line 18: / Line 18: @@
 * power backed by UPS
 * Two types of virtualization:
-** qemu-kvm managed by libvirt (full machine virtualization), our recommend choice for most users
+** Unprivileged Linux Containers (LXC) ([[wikipedia:Operating_system-level_virtualization|OS-level virtualization]]), offered some performance advantages for users running linux guests over full-machine virtualation and reducing the RAM usage. Our recommended choice if you need to run a supported GNU/Linux distribution and your use-case would work in a LXC container
-** Linux Containers (LXC) ([[wikipedia:Operating_system-level_virtualization|OS-level virtualization]]), offered some performance advantages for users running linux guests over full-machine virtualation and reducing the RAM usage
+** qemu-kvm managed by libvirt (full machine virtualization), for everything else