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.