Back to the roots …

Ende 1999 habe ich mit VMWare Work­station angefangen, not­wendi­ges Win­dows-Ärger­nis zu vir­tuali­sieren. Und irgend­wann um 2001 virtua­li­sierte ich meinen ersten Linux-Ser­ver mit User­Mode­Linux

Und nach langen Jahren mit VMWare Server und dann KVM habe ich nun angefangen, mit OpenVZ her­um­zu­spielen (via ProxMox auf ‘nem 9,99-root-Server, der keine Hard­ware­un­ter­stütz­ung für Vir­tuali­sier­ung bietet):

root@gaspode:~# uname -a ; free ; df -h | grep -v none ; vzctl exec 101 uname -a \; free \; df -h \| grep -v none
Linux gaspode 2.6.32-37-pve #1 SMP Wed Feb 11 10:00:27 CET 2015 x86_64 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       4026436    1060428    2966008          0     144480     488400
-/+ buffers/cache:     427548    3598888
Swap:      1047548       1640    1045908
Filesystem               Size  Used Avail Use% Mounted on
udev                      10M     0   10M   0% /dev
tmpfs                    394M  316K  393M   1% /run
/dev/sda1                 20G  1.1G   18G   6% /
tmpfs                    5.0M     0  5.0M   0% /run/lock
tmpfs                    991M   31M  961M   4% /run/shm
/dev/mapper/pve-data     893G  1.5G  846G   1% /var/lib/vz
/dev/fuse                 30M   16K   30M   1% /etc/pve
/var/lib/vz/private/101   20G  437M   20G   3% /var/lib/vz/root/101
Linux trusty2 2.6.32-37-pve #1 SMP Wed Feb 11 10:00:27 CET 2015 x86_64 x86_64 x86_64 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1048576     233428     815148         52          0     224844
-/+ buffers/cache:       8584    1039992
Swap:       524288        636     523652
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs       20G  437M   20G   3% /

Das fühlt sich schon recht »UMLig« an, geht aber natürlich einen Schritt weiter, jedenfalls als ich es in Erinnerung habe.

Was ich damals machte war, eine aus­zu­musternde Hard­ware quasi zu entkörpern; sei es, weil die Hard­ware defekt war/aus­ge­mustert werden sollte, sei es, weil ich auf ak­tuel­lere Soft­ware umstellen wollte, aber für eine Über­gangs­zeit das alte Setup sichern. Was auch immer der Grund, es war recht cool damals, lange, bevor die Pro­zes­soren Un­ter­stütz­ung für so ein An­sin­nen boten, dies mit Linux schon machen zu können.

Ich habe dann später viel mit VMWare Server gemacht, praktisch alle Vir­tualisierungen, bis es um Kernel 2.6.31 herum, das war so 2010, einfach nicht mehr ging. Ich hab’s nicht weiter verfolgt, aber das notwendige Patching des Kernels wurde immer schwieriger, und die VMs fingen an, kurz zu laufen und dann zu sterben, und zwar so, daß das 32-Bit-System rebootet werden mußte, um wieder VMs starten zu können. Mit viel »Liebe« hatte ich dann eine Kon­figuration, die, wenn die VMs 15 Minuten über­lebten, dies auch gerne Mona­te taten.
Dennoch, VMWare Server Version 1 war offen­sicht­lich am Ende der Nütz­lich­keit an­ge­kommen. Mit VMWare Server Version 2 wurde ich nie warm, und so schwenk­te ich dann vor ca. 3 Jahren auf KVM. Da wir damit bei meinem Bröt­chen­geber ebenfalls arbeiteten, war das durchaus eine Win-Win-Si­tua­tion, auch wenn ich VMWare Server schätzte. Denn der benötigte seiner­zeit keine Vir­tua­li­sier­ungs­un­ter­stütz­ung durch die CPU, Vir­tua­li­sierung klappte auch mit so über­sicht­lichen CPU-Features wie diesen: »fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr« — kein ›svm‹ (AMD) oder ›vmx‹ (Intel), und doch waren mehrere VMs möglich. *seufz*

Auftritt Docker:

wusel@luggage:~$ uname -a ; df -h ; sudo docker run -t -i ubuntu:14.04 /bin/bash 
Linux luggage 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda9        96G   90G  1.6G  99% /
udev             10M     0   10M   0% /dev
tmpfs           3.2G  345M  2.8G  11% /run
tmpfs           7.8G   30M  7.8G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda2       100G   79G   17G  84% /data
tmpfs           1.6G   64K  1.6G   1% /run/user/1000
/dev/sdb1        55G   51G  1.5G  98% /media/usb0
tmpfs           1.6G     0  1.6G   0% /run/user/0
root@563a04958b79:/# uname -a ; df -h
Linux 563a04958b79 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 x86_64 x86_64 GNU/Linux
Filesystem      Size  Used Avail Use% Mounted on
rootfs           96G   90G  1.6G  99% /
none             96G   90G  1.6G  99% /
tmpfs           7.8G     0  7.8G   0% /dev
shm              64M     0   64M   0% /dev/shm
/dev/sda9        96G   90G  1.6G  99% /etc/hosts
tmpfs           7.8G     0  7.8G   0% /proc/kcore

Mit Docker – oder LXC, Linux Containern – scheint sich der Kreis zu schließen: ich starte nicht mehr einen besonderen Linux-Kernel, der dann weitere Prozesse unter sich startet, ich starte ein weitgehend normales Linux in einem Wunderland von Namespaces, recht ähnlich zu OpenVZ, nur daß das eben – Erinnerungen an Xen vs. KVM werden wach – out-of-the-box mit aktuellem Kernel tut, anders als eben bei OpenVZ.

Überrascht war ich, daß es UML – User­Mode­Linux – nach wie vor gibt, und au­gen­schein­lich hat sogar lib­virt Support dafür. Aber, die Ka­ra­vane zieht weiter, und für An­wend­ungen ers­cheint mir der LXC-/Docker-Ansatz gar nicht so verkehrt. Also, wenn wir bei Standard­ports und -Anwendungen – Apache, postfix usw.; ggf. OpenVPN – bleiben ;) Denn, leider, batman_adv tut derzeit nicht wirklich im LXC-Umfeld, für Freifunk sind Linux-Container oder auch OpenVZ also derzeit nicht zielführend. Was an sich schade ist, denn die sog. Gateways brauchen primär CPU-Leistung für fastd und Netzwerk-I/O, beides dürfte mittels der ›chroot Deluxe‹ statt der voll­ständigen Simu­la­tion eines PCs per­for­man­ter sein. Auf der anderen Seite werden die CPUs noch immer schneller/effi­zienter …