Das Dokument beschreibt die Migration bestehender Virtualisierungsumgebungen zu Proxmox VE, einschließlich der Gründe für die Migration wie veraltete Software und hohe Betriebskosten. Es werden Voraussetzungen für die Migration, verschiedene Möglichkeiten zur Datenmigration, verwendbare Tools sowie empfohlene Vorgehensweisen dargestellt. Zusätzlich werden Strategien für unterschiedliche Quellumgebungen und gegebenenfalls erforderliche Nacharbeiten erläutert.

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