Vortrag auf der Proxtalks 2016 Berlin: Wie man erfolgreich von bestehender Hardware oder anderen Virtualisierungsumgebungen zu Proxmox VE migriert

1. Proxtalks 2016
Migration zu ProxmoxVE
BestehendeVirtualisierungsumgebungen
zu ProxmoxVE migrieren
10/2016 – Marco Gabriel
Bild: (CC BY SA 2.0) flickr.com - Melv_L - MACASR

2. inett GmbH
• Linux Systemhaus in Saarbrücken
• Gegründet 2007
• ~10 Mitarbeiter
• Proxmox Partner und ProxmoxTraining Partner
• ProxmoxVE Projekte undTrainings in Deutschland, Österreich, Schweiz,
Luxemburg und weiteren Ländern

3. Gründe für die Migration
Die bestehendeVirtualisierungslösung...
• ist „in die Jahre“ gekommen
• genügt zukünftigen Anforderungen nicht mehr
• läuft nicht auf neuer Hardware
• unterstützt neue Gastbetriebssysteme nicht
• verursacht zu hohe Betriebskosten
• verursacht bei einer Erweiterung hohe Kosten (CC BY SA 2.0) flickr.com - Karl Baron

4. Voraussetzungen prüfen
• Server / Hardware
• Hochverfügbarkeit geplant?
• Wie viele Server mit welcher Ausstattung?
• Storage weiterverwenden oder ersetzen?
• Welche Storage für meine Anforderungen? Lokal, zentral, verteilt?
• Netzwerkinfrastruktur
• 10 Gbit/s benötigt, z.B. für Ceph Storage?
• Redundanz bedacht?

5. Quelle
• Physikalischer Server (P2V)
• Vmware
• XEN
• Hyper-V
• OpenVZ
• Sonstige

6. Möglichkeiten
• Einfach, wenn ein gängiges Image existiert
• raw, qcow2, vmdk (flat, nicht gestückelt)
• Auf ProxmoxVE Host kopieren
• NeueVM Konfiguration erstellen
• Image einbinden
• Eventuelle Inkompatibilitäten beiTreibern

7. Möglichkeiten
• Oft zumindest möglich, selbst bei exotischen Images
• qemu-img CLITool verwenden
• Supported formats: vhdx vmdk blkreplay gluster file bochs raw vdi luks iscsi qcow
host_cdrom sheepdog host_device qed quorum parallels null-aio cloop null-co blkverify
zeroinit nbd tftp ftp blkdebug ftps https http dmg rbd vvfat qcow2 vpc
• qemu-img convert [--object objectdef] [--image-opts] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T
src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S
sparse_size] filename [filename2 [...]] output_filename
• qemu-img convert –f vhdx –O qcow2 QuellImage.vhdx ZielImage.qcow2

8. Möglichkeiten
• Häufiger: Backup und Restore direkt aus derVM
• Toll:Wiederherstellung auf abweichender (VM) Hardware
• Immer seltener: Converter von anderen Hypervisoren
• VMware Converter, Microsoft Systems Center
• Eigentlich für eine andere Zielplattform
• Kann funktionieren

9. Der letzte Strohhalm
• Manchmal: Applikationsmigration
• Server Neuinstallation mit Datenmigration
• Je nachApplikation sogar ohne Downtime möglich
• Aufwendig
• Eher für wenigeAusnahmen geeignet, nicht für die generelle Migration

10. Tools
• Open Source
• CloneZilla Boot CD
• SystemRescueCD
• fsarchiver, mondobackup, dd, (g)ddrescue
• Kommerziell
• Windows Backup
• Sonstige Backup Hersteller mit Imaging und Bare Metal Restore

11. Weiterführend: PVEWiki
• ProxmoxVEWiki: Migration von Servern 
http://pve.proxmox.com/wiki/Migration_of_servers_
to_Proxmox_VE

12. „Andere“
• OpenVZ Container  LXC Container
• KVM/Vmware/Hyper-V/<Sonstige> Linux  LXC Container
• OpenVZ Container  KVM

13. OpenVZ  LXC
• OpenVZ bis ProxmoxVE 3.4, LXC ab ProxmoxVE 4.0
• Einfach: OpenVZ Backup, Restore mit LXC
• Netzwerk muss neu konfiguriert werden
• Nicht für alle Distributionen möglich, vor allem ältere funktionieren nicht
• ProxmoxVE gibt beim Restore einen Fehler aus
•  dann benötigen wir eine andere Strategie

14. *  LXC
• Neuen LXCContainer mit gleicher Distribution undVersion installieren
• rsync zur Übernahme der Files
• Auslassen von /etc und den üblichenVerdächtigen wie proc, sys, mnt, dev, ...
• Nacharbeit im Ziel (z.B. /etc zusammenführen)
• Quelle runterfahren, dann finales rsync, Ziel starten
• Höherer, auch manueller Aufwand
• Funktioniert mit fast jeder Quelle, auch mit physikalischen Servern
• Funktioniert sogar umgekehrt, z.B. für OpenVZ  KVM

15. Vorbereiten der Gäste
• Backup erstellen
• Snapshots vor jedem Schritt
• IDETreiber für HDD Controller aktivieren / installieren
• Nicht benötigte Software und alteTreiber deinstallieren
• Gasterweiterungen des alten Hypervisors deinstallieren
STOP: 0x0000007B (0xF741B84C,0xC0000034,0x00000000,0x00000000)
INACCESSIBLE_BOOT_DEVICE

16. Vielen Dank für Ihre Aufmerksamkeit!
Marco Gabriel
inett GmbH
E-Mail: mgabriel@inett.de
Telefon: +49 681 410993-11
Twitter: @MarcoMGabriel
Facebook: fb.com/marcomgabriel
Google+: google.com/+MarcoMGabriel
XING: xing.com/profile/Marco_Gabriel
LinkedIn: linkedin.com/in/marcogabriel1