Schlagwort-Archive: virtualbox

VM Transfer

EIne VM braucht so seine Zeit bis sie eingerichtet ist. Wenn nur das Netz im Hause lahmt, dann kann man diese zu Hetzner umziehen. Ich hab das mal mit Proxmox (Hetzner) und VirtualBox (im Haus) getestet.

Hier die /etc/network/interfaces des Rootservers bei Hetzner mit den Routing für die VMs:

source /etc/network/interfaces.d/*                                                                                                                                                                   
                                                                                                                                                                                                     
auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp0s31f6
iface enp0s31f6 inet static
        address  111.111.111.158 # Main Server IP set by Hetzner
        gateway  111.111.111.129 # Main Server Gateway set by Hetzner
        up route add -net 111.111.111.128 netmask 255.255.255.192 gw 111.111.111.129 dev enp0s31f6
        netmask  255.255.255.192 # Netmask set by Hetzner

iface enp0s31f6 inet6 static
        address  2222:333:172:25dd::2 # Main Server IP set by Hetzner
        netmask  64
        gateway  fe80::1

auto vmbr0 # red interface for Internet connection of VMs
iface vmbr0 inet static
        address  111.111.111.158
        netmask  255.255.255.255
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
        pre-up brctl addbr vmbr0
        up ip route add 99.99.99.81/32 dev vmbr0 # first VM
        up ip route add 99.99.99.82/32 dev vmbr0 # second VM
        up ip route add 99.99.99.83/32 dev vmbr0 # third VM
        up ip route add 99.99.99.84/32 dev vmbr0 # fourth VM
        up ip route add 99.99.99.85/32 dev vmbr0 # fifth VM
        up ip route add 99.99.99.86/32 dev vmbr0 # sixth VM

auto vmbr1 # green interface for local traffix between VMs
iface vmbr1 inet static
        address  10.16.0.1
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

auto vmbr2 # pink interface for VMs which do NAT only
iface vmbr2 inet static
        address  192.168.0.1
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/16' -o enp0s31f6 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/16' -o enp0f31f6 -j MASQUERADE

Man erstellt sich in Proxmox eine KVM VM (hier mit der IP 99.99.99.83) mit ausreichend HDD-Platz, um den zu Hause liegenden Server aufzunehmen. Dabei achtet man in der Proxmox-GUI darauf, dass die Einstellungen möglichst genau denen der zu übetragenden VM in VBox entsprechen – z.B. virtio für die Netzwerkkarten.

Dann zieht man sich ein Live-Medium als ISO (bei Hetzner mit wget -4 weil die IPv6 Namensauflösung länger dauert als der Download) auf dem Proxmox-Server nach /var/lib/vz/template/iso und bindet dieses in der KVM-VM in Proxmox ein. Davon dann booten.

Die Wahl des Tastatur-Layouts gelang VNC in Proxmox bei Ubuntu ISOs hierbei nicht immer, weswegen man auch gleich bei US bleiben kann. Bessere Erfahrungen machte ich mit Lubuntu ISOs.

Ist das Live-Medium gebootet, müssen dessen Netzwerkeinstellungen händisch vorgenommen werden. Dabei können IP und Gateway noch über die grafische Oberfläche festgelegt (meist handelt es sich bei den Live-Medien um den Network-Manager) werden. Als DNS kann man z.B. den von Google (8.8.8.8) nutzen. Das Feld für Gateway bleibt leer. Denn: Die Routen für die KVM-VM müssen händisch mit ip route add gesetzt werden.

# address 99.99.99.83 # set this in NM
# netmask 255.255.255.255 # set this in NM
ip route add 111.111.111.158 dev eth0
ip route add default via 111.111.111.158 dev eth0

Meist muss für eth0 noch der Name des Interfaces an den der KVM-VM angepasst werden. Wie das Interface sich im gegebenen Fall nennt, zeigt ein ifconfig.

Netzwerkverbindung testen.

In der KVM-VM wird zu einer root shell gewechselt und für root ein Passwort vergeben

sudo su -
passwd

Dann einen openssh-server installieren und dessen Konfiguration so anpassen, dass sich root über SSH mit Passwort einloggen darf. Den SSH Server neu starten.

Jetzt kann man schon ausprobieren, ob man sich von der lokalen VBox VM auf dem Live-Medium bei Hetzner einloggen kann.

Klappt das, dann kann es mit dem Transfer der lokalen VBox VM losgehen.

Dazu legt man auf der HDD der KVM-VM zuerst ein Dateisystem an. Im Live-Medium kann man hierzu sogar Gparted nutzen.

Dann mounted man die root Partition (müsste /dev/sda1 sein) der KVM-VM nach /mnt und der eigentliche Transfer erfolgt nun in mindestens zwei Schritten, will man die downtime des lokalen Servers klein halten: Einmal einen rsync aus dem laufenden System heraus. Ein zweites mal, nachdem das lokale System ebenfalls mit einem Live-Medium gebootet wurde, um die Veränderungen auch noch zu übertragen. Ist einem die downtime egal, dann nutzt man am besten gleich lokal ein Live-Medium.

screen rsync -e "ssh -o PubkeyAuthentication=no" --numeric-ids --delete --progress -axAhHSP --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / root@99.99.99.83:/mnt/

Ab jetzt sind wieder die im Vorteil, die viel Bandbreite im Upstream haben. In meinem Fall wird die Übertragung 33 Stunden dauern, was dazu führt, dass mir die Zwangstrennung der Internetverbindung die Übertragung in einem Rutsch vermasselt.

Literatur 1, 2, 3

LM 6.1

Auf linuxmuster.net liegt seit ein paar Tagen die Beta der nächsten Version als VM für alle möglichen VM Hostsysteme. Ich hab das hier mal unter VirtualBox auf meinem Laptop für eine Konfiguration ausprobiert, die nur green und red als Interfaces nutzt.

Die heruntergeladenen Archive lokal mit tar xvfJ archiv.tar.xz entpacken und dann in VBox über das Menü /Datei /Appliance importieren in VBox … naja, eben: importieren. Dann erfolgen einige Anpassungen.

Da ich auf meinem, doch etwas älteren, Laptop als VMHost nur 4GB RAM habe, gab ich der Firewall die voreingestellten 256MB, dem Server 1GB und dem Client unter Lubuntu 512MB. Da musste mein Laptop zwar schwer schnaufen – und auch der virtualisierte Server – aber es läuft, wenn man Lubuntu 12.04 von der Alternate CD installiert .

Firewall

lm6-1_ipfire - Ändern_001

Die MAC Adresse der Netzwerkkarte, die später die rote Schnittstelle werden soll, habe ich hinten mit einer 0 versehen und lasse diese NATen.

lm6-1_ipfire - Ändern_002

Die Schnittstelle, die später mal grün sein soll, versah ich am Ende der MAC mit einer 1 und stellte diese auf „Internes Netzwerk“.

lm6-1_ipfire - Ändern_003

Blau will ich hier auf dem Laptop zum Testen nicht nutzen, also hab ich das „Kabel“ schlicht entfernt und die Schnittstelle nicht angeschlossen.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_004

Beim Hochfahren des IPCop wählte ich nicht den voreingestellten PAE Kernel. Die Firewall kommt mit 256 MB RAM. Da erschien mir das nicht sinnvoll zu sein.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_005

IPFire motzt dann beim Hochfahren, dass es seine Schnittstellen nicht finden kann, was an dieser Stelle nicht weiter stört.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_006

Hat man sich als root und dem Passwort muster einmal eingeloggt, kann man sich durch den Setup-Prozess von IPFire hangeln, den ein setup auslöst.

Die bestehende Zuordnung der Netzwerkkarten muss man zuerst entfernen und dann neu vornehmen. Die vorher vergebenen MAC Adressen helfen bei der Orientierung.

Ein Ping ins Netz zeigt nach Beendigung des Setups, ob alles geklappt hat.

Server

Das Netzwerkinterface des Servers konfiguriert man sich in VBox wie die grüne Schnittstelle des IPFire als „Internes Netzwerk“.

Im Detail ist der Setup-Prozess im Handbuch für Version 6.0 beschrieben.

Nach dem Hochfahren des Servers einloggen (linuxadmin, muster), etwas Zeit verstreichen lassen, bis der Server Kontakt über die VBox interne Schnittstelle zum IPFire erhalten hat und dann mit ping testen, ob die Namensauflösung klappt. Dann mit sudo apt-get update ; sudo apt-get dist-upgrade evtl. vorhandene Updates einspielen und nun – nach einem Wechsel in eine Root-Shell mit sudo su – – das eigentliche Setup beginnen durch Eingabe von

linuxmuster-setup –first

Das kann dauern. LM6.1 zieht nun alle möglichen Pakete aus dem Netz, bis der eigentliche Installationsdialog beginnt (zu diesem siehe den Link zum Handbuch weiter oben).

Subnetting hab ich nicht aktiviert. Ich will vor allem mit Linbo spielen, weil wir schulintern gerade einige Höllenprobleme mit einer zickigen Hardwareklasse (Lenovo T410) haben. Alle anderen Einstellungen habe ich deswegen so übernommen, wie vom Installer als default vorgesehen.

Clients

Die Netzwerkkarten von virtuellen Clients werden wie die grüne Schnittstelle am IPFire bzw. wie die Serverschnittstelle als Internes Netzwerk konfiguriert.

Will man echte Clients testen, dann muss man sich mehr Arbeit machen. In diesem Fall legt man sich auf dem Host-System eine Netzwerkbrücke auf einer unkonfigurierten physischen Schnittstelle ethX an und verpasst dieser eine passende interne IP (siehe Netzwerksetup Homeserver NXT). Statt mit dem Internen Netzwerk von VBox verbindet man dann IPFire und Server mit dieser Bridge.

Ich weiß nicht, ob ich das extra schreiben muss, aber das klappt nur mit Netzwerkschnittstellen am Host in die man ein Kabel stecken kann. WLAN Interfaces sind außen vor. Wer WLAN virtualisiert und keine AccessPoints hierzu nutzen will, kann sich mit USB WLAN Sticks helfen, die man als USB Gerät an die VM durchreicht.

An diese physikalische Schnittstelle des Hosts hängt man einen Switch und an den Switch wiederum den physikalischen Client. Voila.

Sofern die MAC Adressen gleich bleiben, kann man dann zwischen dem physikalischen, ge-bridge-ten Netz und dem VBox internen Netz an den ausgeschalteten VMs hin- und her-schalten wie man will.

VirtualBox NAT Port-Weiterleitung

Wird die nach „Außen“ zeigende Schnittstelle einer VM über VBox NAT geleitet, erscheint diese nicht selbst im Netz, sondern nur der Host. Will man von Außen durch das VBox NAT zurück auf die Gast-Maschine, muss VBox die Weiterleitung der Pakete übernehmen.

Sollte aus Sicherheitsgründen die VM aus einem normalen Benutzeraccount heraus gestartet worden sein, dann weigert sich VBox jedoch, die Ports 1-1024 als Weiterleitungen einzurichten. Diese Ports gehören root. Man kann sich aber wie hier für Port 443 beschrieben helfen und damit auch Webserver-VMs (Port 80 und 443) mit ihrer öffentlichen / roten / nach Außen zeigenden Schnittstelle am VBox NAT betreiben.

Auf dem Router wird eine Weiterleitung auf den Host eingerichtet:

fritzbox_portweiterleitung

Port 443 wird schlicht auf Port 4433 auf dem Host weitergeleitet. Mit Port 80 ginge das genau so. Den könnte man z.B. auf Port 8080 weiterleiten.

Welche Ports man als Weiterleitungsziel wählt ist wie beschrieben egal – Hauptsache diese liegen im Bereich zwischen 1025 und 65536.

vbox_eth_nat

In der VM und dort am ge-nat-etten Adapter klickt man auf „Port-Weiterleitung“.

nat_portforwarding_2

Der Host-Port ist dann der auf dem Router eingestellte Port über 1024 (hier: 4433), der lokale Port ist wieder 443.

Den Apachen muss man also nicht umbiegen. Host-IP und Gast-IP kann man freilassen – die Zuordnung übernimmt dann VBox.

Sollte man die Webserver-VM im orangenen Netz der Firewall liegen haben, dann sind die entsprechenden Regeln auf dieser anzulegen – siehe Netzwerksetup für Homeserver NXT.

Netzwerksetup für Homeserver NXT

Die ID88 bringt wie bereits geschildert zwei Netzwerkschnittstellen mit, die dann an die virtuellen Maschinen durchgereicht werden müssen. Damit dies reibungslos funktioniert und auch die Zusammenarbeit mit dem Router (hier: Fritzbox) klappt, kann man wie folgt vorgehen, um sich eine virtualisierte Firewall zu installieren:

In der Fritzbox wird der DHCP abgeschaltet. Die IP für den Host / den Homeserver wird auf dessen nach Außen / zum Router zeigendem / rotem Interface händisch vergeben. In meinem Fall wäre das eth1 auf dem Host.

  • Der Router hat die IP 192.168.2.1 und nutzt eine Netzmaske 255.255.255.0
  • Das vom Host zum Router zeigende Interface erhält im folgenden Beispiel die IP 192.168.2.200

Auf dem nach Innen / zum Heimnetz zeigenden / grünen Interface des Hosts / Homeservers (in meinem Fall eth0) benötigt man eine Bridge, damit alle virtuellen Maschinen im internen Netz mit ihren eigenen MACs (und damit später auch ihren eigenen IP-Adressen) auftauchen können. Hier ist die IP der Bridge auf dem Host nicht mehr als die IP eines Switches – die IP Adresse des Gastes wird im Gast selbst festgelegt.

  • Nach Innen erhält der Host die IP 10.16.1.100 (eingestellt auf dessen Bridge br0 und nicht auf eth0. Eth0 auf dem Host bleibt komplett unkonfiguriert)
  • Das Heimnetz selbst ist ein 10.16er Netz mit Netzmaske 255.255.0.0 oder  10.16.0.0/16 (damit bekomme ich genug Freiraum für die nächsten Jahre und kann außerdem dafür sorgen, dass Geräte, die ich zwischen Schule und zu Hause hin und her trage immer die gleiche IP haben)

Sollte Ubuntu als Host-Betriebssystem zum Einsatz kommen, dann greift man zur Server-Ausgabe. Diese bringt keinen network-manager mit, der einem beim Setup dazwischen schießen würde. Setzt man eine Desktop-Version ein, dann muss der network-manager zuerst entfernt werden. Das Setup funktioniert nur, wenn man die Interfaces selbst konfigurieren kann.

Zusammengefasst: Auf dem Host steht in /etc/network/interfaces:

# Das Interface in Richtung Router
auto eth1
iface eth1 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 213.73.91.35 192.168.2.1 85.214.20.141

# Das Interface in Richtung Heimnetz
auto br0
iface br0 inet static
address 10.16.1.100
netmask 255.255.0.0
bridge_ports eth0
bridge_fd 5
bridge_stp no

Eth0 auf dem Host bleibt – wie oben schon geschildert – unkonfiguriert. Der Host ist dann aus dem Heimnetz unter der IP der Bridge direkt zu erreichen und lässt sich so leicht warten.

Eth1 auf dem Host habe ich nicht nur mit dem Nameserver auf dem Router, sondern zusätzlich noch mit den DNS des CCC und Foebud versorgt. Man weiß ja nie.

Nun legt man sich die erste Virtuelle Maschine (hier unter VirtualBox, das unter einem normalen Benutzeraccount läuft) mit zwei Netzwerkkarten an.

vbox_eth_nat

Das „zum Router“ zeigende Interface der VM wird als NAT angelegt.

Damit ich die Netzwerkkarten später in der VM wieder finde, schreibe ich deren MAC Adressen immer so um, dass „rot“ eine 1 (für eth1 des Hosts) am Ende hat – und „grün“ eine 0 (für eth0 des Hosts).

vbox_eth_bridged

Das „nach Innen“ ins Heimnetz zeigende Interface der VM wird an die Bridge br0 des Hosts angeschlossen.

Ist der erste Host (hier IPFire als Firewall) gestartet, richtet man dessen Interfaces ebenfalls händisch her. Das nach Außen zeigende, rote Interface erhält vom DHCP auf dem NAT der VirtualBox irgendeine 10er Adresse. Welche, ist relativ egal. Später eingerichtete Portweiterleitungen übernimmt VirtualBox. Wichtig sind die Angaben für das interne, grüne Interface (also das, das an der Bridge des Hosts hängt). Hier muss die /etc/network/interfaces des Gastes angepasst werden (im Falle von IPFire über dessen Weboberfläche).

# Das rote Interface zeigt in Richtung Router und haengt am VBox NAT
auto eth0
iface eth0 inet dhcp

# Das gruene Interface zeigt in Richtung Heimnetz und haengt an der Bridge des Hosts
auto eth1
iface eth1 inet static
address 10.16.1.1
netmask 255.255.0.0

Die erste VM ist aus dem Heimnetz dann unter 10.16.1.1 zu erreichen.

So lange auf dem IPFire noch kein DHCP Server auf grün läuft, muss man sich auf einem Client eine 10.16.er Adresse händisch selbst zuweisen, damit man an die Weboberfläche kommt.

Die Installation weiterer VMs hängt direkt vom Sicherheitsbedürfnis ab. Zwei Wege sind möglich: einer führt über virtuelle Netzwerkkarten an der Firewall-VM (blau und orange), der andere richtet VMs „neben“ der Firewall ein.

vbox_internalnetwork

Wählt man die sicherere Variante (weitere Netzwerkkarten in der Firewall-VM), richtet man diese NICs in VirtualBox als „Internes Netzwerk“ ein. Die VMs hängen dann mit ihrem roten Interface direkt an der Firewall und ebenfalls im VM-internen-Netzwerk. Das wäre z.B. ein Weg, um ein orangenes Netz einzurichten (siehe Bild oben für die Netzwerkkarte eines Webservers im orangen Netz von IPFire).

Aside: Ein blaues Netz ist nicht so einfach zu haben, weil WLAN Karten auf dem Host nicht als solche in VMs hinein gereicht werden können. Man kann sich hier aber mit USB-WLAN-Sticks helfen, die an die VM gebunden und aus dieser heraus konfiguriert werden.

Wählt man die unsicherere Variante, richtet man weitere VMs „neben“ der Firewall ein. Das Setup entspricht hierbei jeweils der Einrichtung der ersten VM: Eth1 des Gastes mit VBox-NAT zeigt nach Außen. Die nach Innen zeigende Schnittstelle des Gastes (eth0) wird im Gast händisch mit einer IP versorgt und klebt an der Bridge br0 auf dem Host.

Fällt ein derartiger Gast in fremde Hände, steht dem Angreifer das komplette interne Netz offen. Die Firewall ist hier reduziert auf ihre Webfilter-/DHCP-Funktionen für das interne Netz. Schutz von Außen bietet sie so nur bedingt. Man sollte aber wegen einer derartigen Konstruktion nicht gleich in Panik ausbrechen. Ge-nat-ete VMs dürften von Außen schwer zu knacken sein. Bei Portweilterleitungen vom Router auf eine solche VM macht man jedoch ein Türchen für Angriffe auf und muss eine derartige VM (eine Brücke zwischen Internet und Heimnetz) dann noch einmal gesondert absichern (iptables, fail2ban, tripwire etc. pp.). Oder man spart sich das interne Interface gleich komplett.

Hier vermehren sich die VMs fast täglich: Die Firewall war zuerst da, dann kam ein Fileserver, dann ein Nameserver, ein Webserver, ein Gameserver … 10er Netze und viel RAM auf dem Host lassen viel Raum für Spinnereien 🙂

Zentyal bare metal

Im Kontext des Projektes Homeserver NXT verfolgte ich zuerst eine monolithische (in Nachhinein: blöde) Denke. Firewall, Fileserver und Nameserver integriert Zentyal. Zentyal basiert auf Ubuntu – also wäre da auch der Gameserver integrierbar gewesen. Dazu: eine hübsche, moderne Weboberfläche zur Administration vom Sofa aus. Das wollte ich mir zumindest mal ansehen.

Der erste Versuch, Zentyal direkt auf die Zotac ID88 zu bekommen, klemmte schon am Kernel des Installers, der nicht erkennen wollte, dass ich von USB installierte und nicht von CD. Die Meldung war, wenn ich mich richtig erinnere

Your installation CD-couldn’t be mounted. This probably means that the CD-ROM was not in the drive. If so you can insert it and try again.

Retry mounting the CD-ROM?

Dieser Fehlermeldung kann man abhelfen, wenn man die zentyal.iso mit auf den Stick kopiert, von dem aus man installieren will.

Taucht dann die Fehlermeldung auf, wechselt man mit Alt F2 auf eine Shell, aktiviert diese mit Enter und erstellt sich zuerst ein Verzeichnis, in das man den USB Stick mounten kann:

mkdir /media/stick

mount -t vfat /dev/sdb /media/stick

Dann erstellt man sich ein Loop Device und wirft über dieses dem Ubuntu/Zentyal Installer die gewünschte CD-Rom zum Fraß vor:

mount -t iso9660 -o loop /media/stick/zentyal.iso /cdrom

Mit Alt F1 kommt man zurück zum Installer und kann diesem nun vergaukeln, alles wäre OK.

Zentyal kommt so zwar auf die ID88 – aber das hilft nicht viel, weil die Chips des NICs zu neu sind.

Welcher Idiot kauft auch Hardware mit Realtek Chips?

Sofern man unbedingt die alte Ubuntu 12.04 LTS / Zentyal Distri auf der ID88 haben muss, dann darf man ab hier die Realtek NICs umschiffen, bis ein neuerer Kernel und Treiber an Bord sind. Der einfachste Weg ist, sich die WLAN Karte der ID88 (Intel) zu konfigurieren und über diese dann weiter zu arbeiten. Wie das geht wird hier beschrieben (man kann sich bei den nötigen Schritten auch mit einem lokalen Repo auf USB Stick helfen) – aber ich hatte da schon eingesehen, dass die Idee, Zentyal direkt auf das Metall zu werfen, zu unflexibel ist.

Also kam ein aktueller Ubuntu 13.10 Server (der sich reibungslos vom USB Stick installieren lässt) an Bord, VirtualBox dazu und Zentyal in eine VM. Aber das ist wiederum im nächsten Post beschrieben …

VirtualBox, rdesktop und ssh Tunnel

sshtunnel_rdesktop

Folgendes Setup: In der Schule steht ein VMHost auf dem einige VMs mit Hilfe von VirtualBox virtualisiert wurden. Der VMHost ist von Außen nur über SSH und dort nur über Port 2233 zu erreichen.

Säße man direkt am VMHost würde man die rdesktop-Sitzung mit dem folgenden Befehl aufrufen:

rdesktop localhost:3389

Diese Sitzung will man nun auf dem Laptop zu Hause haben. Also braucht man einen SSH Tunnel in die Schule, über den man sich die rdesktop Sitzung nach Hause holt.

Ein derartiger Aufbau des SSH Tunnels erfolgt wie hier angegeben, wenn man auch lokal die rdesktop Session auf Port 3389 sehen will:

ssh -p 2233 benutzer@vmhost.schule.tld -L 3389:localhost:3389

Lokal macht man dann (in einem zweiten Terminal) die rdesktop Session auf, wie wenn man direkt am VMHost sitzen würde: rdesktop localhost:3389

paedML auf Virtualbox

Hier hatte ich schon einmal kurz beschrieben, wie man sich eine paedML unter VirtualBox einrichtet. Die aktuelle 5.0.4er paedML brauchte ich neulich (zum Zwecke der Bugsuche auf dem Schulserver) mal wieder und deswegen hier eine Aktualisierung der Hinweise.

Zuerst den IPCop einrichten.

Das erste Interface, das dessen Setup-Prozess findet, wird die grüne Schnittstelle. Deswegen wird die erste Netzwerkkarte in VBox gleich auf inet gesetzt.

Dies gilt selbstverständlich nur, wenn man die Server+IPCop Installation für Testzwecke auf dem heimischen Rechner haben will. Virtualisiert man sich die Installation in der Schule mit Hilfe von VBox (was durchaus so performant ist wie unter Xen oder KVM),  dann würde man in diesem Schritt eine der physikalischen NICs des Wirtsrechners im promiscuous Modus wählen – aber hierzu an anderer Stelle mehr.

Die zweite Schnittstelle im IPCop wird später dann das rote Interface und deswegen steht dieses hier und für den geschilderten Zweck (Spielwiese für zu Hause) auf NAT.

Um die beiden Netzwerkkarten im IPCop-Setup leichter unterscheiden zu können, wählt man sich hier einen anderen NIC Typ aus, als für die erste Schnittstelle. Wer sich total vertut, kann aber auch auf dem IPCop selbst die Kartenzuordnungen ändern, ohne ins Setup zu gehen – hier steht wie.

Im Setup des IPCop dann für GREEN den gewünschten Adressbereich auswählen (10.16.1.1 etc.) – für RED wird DHCP ausgewählt, was einem die restliche Konfiguration erspart (DNS usw). Ist der Cop mal an Bord, dann diesen booten und mit ping überprüfen, ob er ins Netz kommt. Erst weitermachen, wenn auch die Namensauflösung klappt.

Dann den 5.0.4er Server aufsetzen, der bei mir nur mit PAE/NX = aktiv booten wollte:

Dessen Netzwerkkonfiguration ist nun die folgende:

Über die VirtualBox Bridge intnet kommunizieren die beiden miteinander – und auch alle Client-Rechner, die man sich testweise und ebenfalls unter VBox dazu installiert.

Virtualbox saved state recovery

Für den Wirtsrechner kam ein neuer Kernel, ein Reboot wurde notwendig. Auf mein Virtualbox Start-Stop-Skript vertrauend startete ich den Wirt neu, ohne vorher die virtuellen Maschinen einzeln anzuhalten oder einzufrieren – was auch bei den meisten reibungslos funktionierte, nicht jedoch bei der virtualisierten paedML. Die warf mir nach dem Reboot die folgende Meldung entgegen:

The VM is missing a block device. Please make sure the source and target VMs have compatible storage configurations

Ein Beitrag im Forum bei Virtualbox lies vermuten, dass die Lösung nah ist. Hier wird empfohlen, in der .vbox Datei den stateFile=“{xxxxxxxxxx-xxxx-xxxx-xxxxxxxx}.sav“ Eintrag zu löschen. Leider half das bei mir nicht.

Dafür half es, den saved state zu verwerfen. In der grafischen Oberfläche ist das lediglich ein Klick auf den Knopf Discard. VBox warnt dann, dass dies dem Ziehen des Netzsteckers gleichkomme … was auch nicht weiter schlimm ist. Im dümmsten Fall bekommt fsck Arbeit.

Es geht aber auch auf der Shell mit

vboxmanage discardstate name_der_vm

wie das Handbuch zu VBox ausführt.

VirtualBox Start Stop Script

Um auf einem Wirtsrechner mehrere Instanzen von unter Virtualbox laufenden VMs mit dem Wirt selbst zu starten und zu stoppen, brauchten wir entsprechende start-stop-Skripte. Fündig wurden wir im Forum von Virtualbox:

http://forums.virtualbox.org/viewtopic.php?f=7&t=34790

Eine Alternative sahen wir uns ebenfalls noch an, entschieden dann aber für das Skript von Nicolas Tessore. Trotzdem – wenigstens noch der Link: http://www.glump.net/howto/virtualbox_as_a_service

Das Skript von N.Tessore passten wir ein klein wenig bei Require-Start an und dokumentieren dies nun hier. Es läuft reibungslos auf einem Ubuntu Server 10.04 LTS 64 bit und Virtualbox 4.1 – für andere VBox- und Ubuntu-Versionen sollte es anpassbar sein:

#! /bin/sh
### BEGIN INIT INFO
# Provides: vbox-headless
# Required-Start: $syslog $vboxdrv $network
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start VMs in headless mode.
# Description: This script runs VMs for the default VirtualBox
# user in headless mode. Make sure all VMs are using different
#  RDP ports.
### END INIT INFO

# Author: Nicolas Tessore <n.tessore@gmail.com>

####
# VirtualBox settings
####

# The user which owns the VMs
VBOX_USER=username

# The list of VMs to run. Leave empty to run all registered VMs.
VBOX_LIST=““

# VirtualBox executables
VBOX_MANAGE=/usr/bin/vboxmanage
VBOX_HEADLESS=/usr/bin/vboxheadless

####
# End VirtualBox settings
####

# Do NOT „set -e“

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC=“VirtualBox daemon“
NAME=vbox-headless
DAEMON=$VBOX_HEADLESS
DAEMON_ARGS=““
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x „$DAEMON“ ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

vm_init_list()
{
# get registered VMs
LIST_VMS=`sudo -H -u $VBOX_USER $VBOX_MANAGE –nologo list vms | cut -d ‚ ‚ -f 1 | tr -d ‚“‚`

# check for list of VMs
if [ -z „$VBOX_LIST“ ]
then
# all registered VMs for user
VBOX_LIST=$LIST_VMS
else
# check that VMs exist
for VM in $VBOX_LIST
do
case $LIST_VMS in
„$VM“)
continue
;;
*)
log_failure_msg „ERROR: VM ‚$VM‘ is not registered!“
exit 1
;;
esac
done
fi
}

# get uuid for vm
vm_get_uuid()
{
vm=$1
hwuuid=`sudo -H -u $VBOX_USER $VBOX_MANAGE –nologo showvminfo –machinereadable „$vm“ | grep ‚hardwareuuid=’`
echo $hwuuid | cut -d ‚=‘ -f 2 | tr -d ‚“‚
}

# control running vm
vm_ctrl()
{
sudo -H -u $VBOX_USER $VBOX_MANAGE –nologo controlvm $1 $2 > /dev/null 2>&1
}

#
# Function that starts the daemon/service
#
do_start()
{
vm_init_list

# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
RETVAL=0

# Start all VMs
for VM in $VBOX_LIST
do
VM_UUID=`vm_get_uuid $VM`
VM_PIDFILE=“$PIDFILE.$VM_UUID“
VM_DAEMON=“$DAEMON“
VM_DAEMON_ARGS=“$DAEMON_ARGS –startvm $VM_UUID“

log_action_begin_msg „Starting VM ‚$VM'“

# test for running VM
USER=$VBOX_USER LOGNAME=$VBOX_USER start-stop-daemon \
–start \
–quiet \
–pidfile $VM_PIDFILE \
–startas $VM_DAEMON \
–test \
> /dev/null

# VM already running
if [ „$?“ != 0 ]
then
# report VM is running
log_warning_msg „VM ‚$VM‘ already running“
[ „$RETVAL“ = 0 ] && RETVAL=1
continue
fi

# start VM
USER=$VBOX_USER LOGNAME=$VBOX_USER start-stop-daemon \
–start \
–quiet \
–pidfile $VM_PIDFILE \
–make-pidfile \
–background \
–chuid $VBOX_USER \
–startas $VM_DAEMON \
— $VM_DAEMON_ARGS

log_action_end_msg „$?“

# check if start failed
if [ „$?“ != 0 ]
then
# report error
log_failure_msg „Error starting VM ‚$VM'“
RETVAL=2
fi
done

if [ „$RETVAL“ -lt 2 ]
then
log_daemon_msg „VirtualBox daemon started successfully“
else
log_daemon_msg „VirtualBox daemon started with errors“
fi

return „$RETVAL“
}

#
# Function that stops the daemon/service
#
do_stop()
{
vm_init_list

# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
RETVAL=0

for VM in $VBOX_LIST
do
VM_UUID=`vm_get_uuid $VM`
VM_PIDFILE=“$PIDFILE.$VM_UUID“

log_action_begin_msg „Stopping VM ‚$VM'“

# try savestate halt
vm_ctrl $VM savestate

# stop daemon
USER=$VBOX_USER LOGNAME=$VBOX_USER start-stop-daemon \
–stop \
–quiet \
–retry=TERM/30/KILL/5 \
–pidfile $VM_PIDFILE

case „$?“ in
0)
log_action_end_msg 0
;;
1)
log_warning_msg „VM ‚$VM‘ already stopped“
[ „$RETVAL“ = 0 ] && RETVAL=1
;;
2)
log_action_end_msg 1
log_failure_msg „ERROR: Could not stop VM ‚$VM'“
RETVAL=2
continue
;;
esac

rm -f $VM_PIDFILE
done

if [ „$RETVAL“ -lt 2 ]
then
log_daemon_msg „VirtualBox daemon stopped successfully“
else
log_daemon_msg „VirtualBox daemon stopped with errors“
fi

return „$RETVAL“
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon –stop –signal 1 –quiet –pidfile $PIDFILE –name $NAME
return 0
}

case „$1“ in
start)
log_daemon_msg „Starting $DESC“ „$NAME“
do_start
case „$?“ in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg „Stopping $DESC“ „$NAME“
do_stop
case „$?“ in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
status)
status_of_proc „$DAEMON“ „$NAME“ && exit 0 || exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave ‚force-reload‘ as an alias for ‚restart‘.
#
#log_daemon_msg „Reloading $DESC“ „$NAME“
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the „reload“ option is implemented then remove the
# ‚force-reload‘ alias
#
log_daemon_msg „Restarting $DESC“ „$NAME“
do_stop
case „$?“ in
0|1)
do_start
case „$?“ in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo „Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}“ >&2
echo „Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}“ >&2
exit 3
;;
esac

:

In diesem Pastebin liegt es auch noch rum, sollte Copy and Paste aus WordPress mal wieder zickig sein:

http://pastebin.com/4i8W0FB2

Mit Hilfe von

update-rc.d  vbox-headless start 99 2 3 4 5 . stop 99 0 1 6 .

konnte das Skript dann zwar in die richtigen Ordner

/etc/rc2.d/S99vbox-headless
/etc/rc3.d/S99vbox-headless
/etc/rc4.d/S99vbox-headless
/etc/rc5.d/S99vbox-headless

eingefügt werden, aber – komisch, komisch – nicht an der 99. Stelle, sondern immer nur an der 20. Diese Anpassung musste also von Hand vorgenommen werden.

Das wirklich coole an N.Tessores Skript ist, dass es die VMs nicht herunterfährt, sondern bei einem Serverreboot schlicht pausieren lässt. So sind die VMs nach dem Start des Wirtsrechners sofort wieder da.

VirtualBox VDI verkleinern

Ich backe gerade eben für meine Schule eine virtuelle Maschine mit Ubuntu Lucid und ksociograma für die Erstellung von Soziogrammen. Leider wächst der VDI Container aber immer stärker, als er eigentlich müsste, weil Ubuntu ja zuerst die Pakete herunterlädt und dann installiert. Ich kann die Pakete dann in der VM zwar mit

sudo apt-get clean

sudo apt-get autoremove

wieder rauswerfen und damit die VM putzen – das ändert aber an der Größe der VM nichts mehr. Die bleibt auf der Wirtsplatte so dick, wie sie war.

Einige Anleitungen im Netz beschreiben nun, wie man die VDI Datei wieder verkleinert – aber leider stimmt keine der von mir gefundenen zu 100%. Deswegen hier eine Beschreibung des Vorgangs, der bei mir für einen Linux-Gast funktioniert hat:

Zu beachten: Die VM (der Linux-Gast) ist mit EXT3 als Dateisystem anzulegen – sonst klappen die folgenden Schritte nicht!

Nachdem alle Programm installiert sind und die VM geputzt wurde (siehe oben), wird diese herunter gefahren. Dann wird die VM mit einer Ubuntu Desktop-CD gebootet. In dieser wechselt man auf eine Root-Shell

sudo su –

und installiert sich das Programm zerofree, das nur mit EXT3 als Dateisystem klar kommt

apt-get install zerofree

Exkurs: Wenn man sich Platte des Gastes einmal kurz einhängt (mount -t ext3 /dev/sda1 /mnt), dann zeigt ein df -h in der VM an, wie viel Platz noch vorhanden ist und liefert einem außerdem alle Gerätenamen – in meinem Fall ist die Platte des Gastes /dev/sda1. Nicht vergessen: Die Platte muss nach diesem Schritt wieder ausgehängt werden, damit die folgenden Schritte funktionieren: umount /mnt

Dann wird die Platte der VM read-only in die Desktop-Umgebung gemountet

mount -o ro -t ext3 /dev/sda1 /mnt

und zerofree drauf losgelassen

zerofree /dev/sda1

Nachdem das Progrämmchen fertig ist, kann die VM herunter gefahren und die VDI Datei vom Wirt aus geschrumpft werden:

VBoxManage modifyvdi /pfad/zur/vm.vdi compact

Endlich keine device busy Meldungen mehr, wenn man versucht, zerofree aus der VM heraus auf die eigene Platte los zulassen.