Tag Archives: virtualisierung

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

(C) leonlai @ sxc

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.

Netzwerkkartenwechsel

(C) somadjinn @ sxc

Bei der Virtualisierung bestehender Maschinen erhalten diese in ihrer dann virtuellen Umgebung einen anderen Netzwerkkarten Typ und damit auch eine neue Schnittstellen-Bezeichnung. Dies sorgt dann für Probleme, wenn z.B. eth0 auf eine fixe IP Adresse gelegt war, sich nun die virtuelle Maschine mit der “neuen” Karte aber so fühlt, als hätte diese nur eth1. Diese Schnittstelle ist dann nämlich nicht konfiguriert und die VM kommt nicht ins Netz.

Abhilfe schafft die Bearbeitung der Datei

/etc/udev/rules.d/70-persistent-net.rules

In diese trägt Ubuntu ein, welcher Karte es welche Schnittstellen-Bezeichnung zugewiesen hat und hier kann man dann die nicht benötigten Zuweisungen (an die nicht mehr vorhandenen Karten) löschen und die bestehenden anpassen (also eth1 durch eth0 ersetzen).

Reboot und tut.

Auch praktisch ist dieses Vorgehen auf einem IPCop, der zwei identische NICs verbaut hat. Da darf man im Setup nämlich raten, welche NIC nun welches Netz erhalten hat. Kein Drama, wenn es den IPCop in real gibt. Da steckt man schlicht die Kabel um. Wenn man jedoch einen UnCop aufgesetzt hat und ein Interface an einer Bridge hängt, dann ist das schon fummeliger, weil die Re-konfiguration im Virtualisierer erfolgen muss.

Einfacher geht es durch Anpassung dieser Datei auf dem IPCop selbst:

/var/ipcop/ethernet/settings

Nach einem Reboot klappt es dann wieder mit der Verbindung.

KVM Bridging

(C) sweetiluv @ sxc

Ein Server mit 6 Netzwerkschnittstellen und jede davon soll unter KVM einen eigenen Gast und eine eigene IP bekommen – das war die Aufgabe und am Bridging wäre es fast gescheitert, hätte ich nicht diesen Blogpost hier gefunden:

http://blog.agdunn.net/?p=416

Was bis zur Lektüre des obigen Posts nicht recht hatte klappen wollen war das richtige Erstellen der Netzwerkbrücken für die KVM Gäste. Dabei – wenn mal es mal weiß – ist es simpel: Zuerst muss ein evtl. vorhandener Netzwerkmanager runter

apt-get remove network-manager

und die erste Schnittstelle am Rechner muss händisch konfiguriert werden, damit dieser weiterhin eine Internetverbindung hat – im folgenden: Wirt. Für jede Schnittstelle (und damit also für jede IP und jeden KVM Gast) legt man sich sodann eine Netzwerkbrücke an. Der KVM Gast wiederum nutzt diese Brücke um damit ins Netz zu kommen. TUN/TAP Interfaces etc. sind nicht nötig. Will man dafür sorgen, dass zwei KVM Gäste miteinander im gleichen Netz hängen, dann verbindet man diese mit der gleichen Brücke.

Hier – genau wie für die folgenden Schritte – empfiehlt es sich, auf ein /etc/init.d/networking restart zu verzichten und lieber den ganzen Server nach Anpassungen der Netzwerkonfiguration neu zu booten. Manchmal treten sonst Merkwürdigkeiten auf.

Ich zeig das mal für zwei der NICs am Server: Für einen virtualisierten IPCop (also einen UnCop) mit zwei Netzwerkkarten (rot und grün) reichen die folgenden zusätzlichen Einträge auf dem Wirt in

/etc/network/interfaces

Dabei gehe ich davon aus, dass der Server (Wirt) über eth0 mit dem Internet verbunden ist (die IP Adressen im folgenden Beispiel sind für die eigenen Bedürfnisse anzupassen):

# The loopback network interface
auto lo
iface lo inet loopback

# Network interface links directly to Provider
auto eth0
iface eth0 inet static
address 141.11.38.149
netmask 255.255.255.248
network 141.11.38.144
broadcast 141.11.38.151
gateway 141.11.38.145
# dns-* controlled by resolvconf
dns-nameservers 129.11.2.4
dns-search my.domain

und der IPCop unter KVM die Schnittstelle eth1 (des Wirts) für Rot und eth2 (des Wirts) für Grün erhalten soll:

# KVM controlled Interfaces
# The IPCOP network interface, used by br1
# RED
auto eth1
iface eth1 inet manual
# The bridge network interface, used by kvm
auto br1
iface br1 inet manual
bridge_ports eth1
bridge_stp yes
bridge_fd 0
bridge_maxwait 0
# IPCOP network interface, used by br2
# GREEN
auto eth2
iface eth2 inet manual
# The bridge network interface, used by kvm
auto br2
iface br2 inet manual
bridge_ports eth2
bridge_stp yes
bridge_fd 0
bridge_maxwait 0

br2 ist dann die Schnittstelle, an die sich auch weitere virtualisierte Rechner anschließen lassen, um selbst über den UnCop ins Internet zu kommen. Ein Kabel in eth2 (br2) kann zu einem Switch führen und weitere, nicht virtualisierte Clients anbinden. Genau die richtige Mischung, wenn auf der grünen Karte des IPCop ein DHCP Server läuft.

VMWare VMDK verkleinern

(C) leonlai @ sxc

Wenn ich für VirtualBox arbeite, dann halt auch für VMWare. Das läuft unter Windows Hosts schließlich stabiler und dürfte Dank des freien Players auch an Schulen nutzbar sein. Hier gestaltet sich die Verkleinerung aus dem Ubuntu Lucid Gast heraus einfacher.

Zuerst werden wieder alle nicht benötigten Pakete und der ganze Müll rausgeworfen:

sudo apt-get autoremove ; sudo apt-get clean

Dann werden im Lucid Gast die VMWare Tools installiert:

sudo apt-add-repository ‘deb http://packages.vmware.com/tools/esx/4.1latest/ubuntu lucid main restricted’

sudo wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub -q -O- | sudo apt-key add -

sudo apt-get update

sudo apt-get install vmware-open-vm-tools

Es folgt ein reboot.

Ein

sudo vmware-toolbox

startet die Toolbox und erlaubt das shrinken direkt aus dem Gast heraus.

VirtualBox VDI verkleinern

(C) leonlai @ sxc

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.