Proxtalks 2016Migration zu Proxmox VE

Bestehende Virtualisierungsumgebungen zu Proxmox VE migrieren10/2016 – Marco Gabriel

Bild: (CC BY SA 2.0) flickr.com - Melv_L - MACASR

inett GmbH

• Linux Systemhaus in Saarbrücken• Gegründet 2007• ~10 Mitarbeiter• Proxmox Partner und Proxmox Training Partner• Proxmox VE Projekte und Trainings in Deutschland, Österreich,

Schweiz, Luxemburg und weiteren Ländern

Gründe für die Migration

Die bestehende Virtualisierungslö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

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?

Quelle

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

Möglichkeiten

• Einfach, wenn ein gängiges Image existiert• raw, qcow2, vmdk (flat, nicht gestückelt)• Auf Proxmox VE Host kopieren• Neue VM Konfiguration erstellen• Image einbinden• Eventuelle Inkompatibilitäten bei Treibern

Möglichkeiten

• Oft zumindest möglich, selbst bei exotischen Images• qemu-img CLI Tool 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

Möglichkeiten

• Häufiger: Backup und Restore direkt aus der VM• 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

Der letzte Strohhalm

• Manchmal: Applikationsmigration• Server Neuinstallation mit Datenmigration• Je nach Applikation sogar ohne Downtime möglich• Aufwendig• Eher für wenige Ausnahmen geeignet, nicht für die generelle Migration

Tools

• Open Source• CloneZilla Boot CD• SystemRescueCD• fsarchiver, mondobackup, dd, (g)ddrescue

• Kommerziell• Windows Backup• Sonstige Backup Hersteller mit Imaging und Bare Metal Restore

Weiterführend: PVE Wiki

• Proxmox VE Wiki: Migration von Servern http://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE

„Andere“

• OpenVZ Container LXC Container• KVM/Vmware/Hyper-V/<Sonstige> Linux LXC Container• OpenVZ Container KVM

OpenVZ LXC

• OpenVZ bis Proxmox VE 3.4, LXC ab Proxmox VE 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• Proxmox VE gibt beim Restore einen Fehler aus• dann benötigen wir eine andere Strategie

* LXC

• Neuen LXC Container mit gleicher Distribution und Version installieren• rsync zur Übernahme der Files• Auslassen von /etc und den üblichen Verdä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

Vorbereiten der Gäste

• Backup erstellen• Snapshots vor jedem Schritt• IDE Treiber für HDD Controller aktivieren / installieren

• Nicht benötigte Software und alte Treiber deinstallieren• Gasterweiterungen des alten Hypervisors deinstallieren

STOP: 0x0000007B (0xF741B84C,0xC0000034,0x00000000,0x00000000)INACCESSIBLE_BOOT_DEVICE

Vielen Dank für Ihre Aufmerksamkeit!

Marco Gabrielinett GmbHE-Mail: mgabriel@inett.deTelefon: +49 681 410993-11Twitter: @MarcoMGabrielFacebook: fb.com/marcomgabrielGoogle+: google.com/+MarcoMGabrielXING: xing.com/profile/Marco_GabrielLinkedIn: linkedin.com/in/marcogabriel1