Schlagwort-Archive: kvm

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:

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.

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

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.

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

KVM Bridging

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.