VMware war seit Langem Vorreiter und Branchenprimus in Sachen Virtualisierung – ob bei Workstations mit VMware Workstation oder bei Serverumgebungen mit VMware ESXi Server. Seit der Übernahme durch Broadcom und der neuen Firmenpolitik wie der Einstellung unbefristeter Lizenzen und steigender Kosten über Abonnements, die auf der Anzahl der CPU-Kerne basieren, überprüfen Unternehmen ihre Infrastrukturen und die darin enthaltenen Lösungen. Bei dieser Suche nach Alternativen erweist sich OpenStack als strategische und äusserst günstige Lösung für Unternehmen jeder Grösse.
OpenStack bietet gegenüber VMware ESXi Server viele Vorteile:
- Mehr Flexibilität bei Soft- und Hardware
- Deutliche Senkung der Kosten (insbesondere bei Software-Lizenzen)
- Kein Vendor-Lock-in (Open-Source-Lösung mit offenen technischen Standards)
- Garantierte Interoperabilität
Doch kommen wir zur Kernfrage: Wie können eine oder mehrere virtuelle Maschinen mit VMware ESXI Server-Technologie zu OpenStack-Infrastrukturen migriert werden?
1. Technische Voraussetzungen
- Eine Instanz in der Ziel-OpenStack-Infrastruktur mit Rocky Linux-Betriebssystem (oder gleichwertig), das in diesem Artikel durchgehend als «Migrationsappliance» bezeichnet wird. Bei den Migrationen wird diese Instanz als «Durchreiche» verwendet und benötigt direkten Zugriff auf das / die Zielvolumen der zu migrierenden virtuellen Maschinen. Ich persönlich werde die Public Cloud von Infomaniak nutzen, die im Vergleich zu AWS, GCP oder Azure äusserst günstig ist.
- Einen SSH-Zugriff (nur Port 22) auf die ESXi-Server über die Migrationsappliance (entweder über Login und Kennwort oder über SSH-Schlüssel).
- Alle in diesem Artikel genannten Aktionen sind mit dem root-Benutzer durchzuführen.
💡 Bevor es richtig losgeht, noch zwei wichtige Hinweise:
- Diese Vorgehensweise gilt nur für VMware ESXi und nicht für vSphere. Wenn Sie sich die Dokumentation der in diesem Artikel verwendeten Lösungen ansehen, können Sie diese bei Bedarf problemlos anpassen.
- Sichern Sie Ihre virtuellen Maschinen vor dem Migrationsprozess! Ich will keinesfalls an Ihren nächsten schlaflosen Nächten schuld sein, wenn etwas schiefgeht!
Das war’s schon!! Kommen wir nun zur Konfiguration unserer Migrationsappliance 🚀
2. Installation der Migrationsappliance
Damit unsere Migrationsappliance funktionsfähig ist, müssen nach der SSH-Verbindung einige Pakete installiert werden:
dnf install centos-release-openstack-caracal dnf install python-openstackclient virt-v2v
3. Authentifizierung und Login
Vor Beginn unserer ersten Migration sind noch zwei Schritte durchzuführen, damit sich unsere Migrationsappliance mit unserem ESXi-Server und unserer OpenStack-Plattform verbinden kann:
- Für die Authentifizierung am ESXi-Server gibt es zwei Möglichkeiten: entweder per Schlüsselpaar oder mit Benutzername und Kennwort.
- Für die Authentifizierung mit der OpenStack-Plattform muss die Profildatei openrc abgerufen und an unsere Migrationsappliance gesendet werden.
3.1 Authentifizierung mit dem ESXi-Server
Ich gehe davon aus, dass die Firewall-Regeln zwischen Ihrer OpenStack-Instanz und Ihrem ESXi-Server richtig eingestellt und funktionsfähig sind. Gleiches gilt für die Aktivierung des SSH-Dienstes auf dem ESXi-Server.
Wer keine Authentifizierung mittels Schlüsselpaar einrichten will, möge direkt zum nächsten Abschnitt über die Authentifizierung mit der OpenStack-Plattform gehen.
Wir werden nun unsere Authentifizierung mittels Schlüsselpaar einrichten. Das ist simpel, wir gehen dazu einfach zu unserer Migrationsappliance und führen die folgenden Befehle aus:
- Zuerst generieren wir unser Schlüsselpaar (das Schlüsselpaar verwendet RSA, um die Kompatibilität mit älteren ESXi-Versionen zu maximieren):
ssh-keygen -t rsa -b 4096
- Sobald Ihr Schlüsselpaar generiert ist, stellen wir es auf unserem ESXi-Server bereit:
ssh-copy-id root@IP_SERVEUR_ESXI
Mit diesem Befehl werden Sie aufgefordert, das root-Kennwort Ihres Virtualisierungsservers einzugeben, wobei Ihr öffentlicher Schlüssel auf diesen kopiert wird. Dadurch entfällt künftig die Kennworteingabe, wenn Sie sich bei Ihrem Server anmelden.
Überprüfen Sie nun, ob alles korrekt funktioniert, und versuchen Sie, sich direkt über die Migrationsappliance mit Ihrem ESXi-Server zu verbinden.
Wenn Sie die Authentifizierung mit Benutzername und Kennwort verwenden möchten, müssen Sie lediglich eine Textdatei mit dem Kennwort Ihres ESXi-Servers in Ihrer Migrationsappliance erstellen:
touch passwordfile echo ‘MOT_DE_PASSE_ESXI’ > passwordfile
Selbstverständlich können Sie ebenfalls überprüfen, ob die Anmeldeinformationen korrekt sind, und testweise eine Verbindung zu Ihrem ESXi-Server aufbauen.
3.2 Authentifizierung mit der OpenStack-Plattform
Nun steht die Authentifizierung unserer Appliance bei der OpenStack-Plattform an. Dazu müssen Sie die Profildatei openrc an Ihre Instanz senden, die vor der Ausführung vom Horizon-Dashboard abgerufen wird.
Um zu bestätigen, dass Sie bei der OpenStack-Plattform authentifiziert sind, können Sie den folgenden Befehl ausführen:
Openstack token issue
4. Beginn der Migrationen der virtuellen Maschinen
Für die Migration unserer virtuellen Maschinen verwenden wir das von RedHat entwickelte Dienstprogramm virt-v2v, das speziell für solche Szenarien vorgesehen ist und bereits alle erforderlichen Funktionen und Optionen umfasst. Vereinfacht gesagt erstellt virt-v2v ein neues Volumen in dem OpenStack-Projekt, in dem sich Ihre Migrationsappliance befindet, um Ihre virtuelle ESXi-Maschine vollständig hineinzukopieren. Sobald die Daten kopiert sind, bereitet virt-v2v das Volumen vor, damit es in einem OpenStack gestartet werden kann.
Noch ein wichtiger Hinweis, bevor es losgeht (wirklich der Letzte – versprochen🙈): Die zu migrierenden virtuellen Maschinen müssen ausgeschaltet sein. Denken Sie auch daran, Ihre Volumenkontingente auf der OpenStack-Plattform zu überprüfen, damit die Migration nicht plötzlich blockiert wird.
Nun kann es wirklich losgehen! 😎
Mit diesem Befehl migrieren wir unsere virtuellen Maschinen. Bitte passen Sie diesen gemäss Ihren Angaben an!
Mit Schlüsselpaar-Authentifizierung
virt-v2v -i vmx -it ssh ssh://root@IP_SERVEUR_ESXI/vmfs/volumes/NOM_DATASTORE/NOM_DE_VM/NOM_DE_VM.vmx -o openstack -oo server-id=ID_INSTANCE_OPENSTACK
Mit Authentifizierung über Benutzername und Kennwort
virt-v2v -i vmx -it ssh -ip FICHIER_MOT_DE_PASSE ssh://root@IP_SERVEUR_ESXI/vmfs/volumes/NOM_DATASTORE/NOM_DE_VM/NOM_DE_VM.vmx -o openstack -oo server-id=ID_INSTANCE_OPENSTACK
💡 Einige Erläuterungen zu diesen Optionen
- Bei den vorherigen Befehlen ist virt-v2v so konfiguriert, dass direkt die VMX-Datei der virtuellen Maschine (-i vmx) verwendet wird. Der Zugriff auf diese Datei erfolgt über das SSH-Protokoll (-it SSH).
- Mit den folgenden Optionen kann angegeben werden, wo sich die VMX-Datei befindet:
- IP_SERVEUR EXSI: IT-Adresse des ESXI-Servers
- NOM_DATASTORE: Name des Datenspeichers, in dem die virtuelle Maschine gespeichert ist
- NOM_DE_VM: Name des Ordners, der die Dateien der virtuellen Maschine enthält
- NOM_DE_VM.vmx: Name der VMX-Datei
- Mit der Option -ip FICHIER_MOT_DE_PASSE wird die Datei spezifiziert, die das Kennwort Ihres ESXi-Servers enthält, wenn Sie die Authentifizierung mit Benutzername und Kennwort verwenden.
- Die Option -o openstack ist eine Zielinformation, mit der signalisiert wird, dass wir unsere virtuelle Maschine an eine OpenStack-Plattform senden. Mit -oo server-id=ID_INSTANCE_OPENSTACK kann die Verwendung unserer Migrationsappliance angegeben werden.
Um die ID Ihrer Migrationsappliance abzurufen, können Sie den folgenden Befehl direkt dort eingeben:
dmidecode -s system-serial-number
Nun läuft die Migration, und wir benötigen nur noch etwas Geduld. ⏱️ Das Tool wird die Informationen zur virtuellen Maschine direkt vom ESXi-Server abrufen. Zudem führt es automatisch die notwendigen Aktionen aus, damit die virtuelle Maschine ordnungsgemäss mit OpenStack funktioniert.
5. Starten der migrierten virtuellen Maschinen
Nach Abschluss der Migration muss unsere Instanz nur noch über die Funktion boot from volume von OpenStack neu gestartet werden. Diese Funktion ermöglicht, für eine Instanz direkt ein bootfähiges Volumen anstatt eines Images zu verwenden, das in ein neues Volumen übertragen wird.
Zu Beginn ist die ID des Volumens abzurufen, das für unsere Migration erstellt wurde. Folglich beginnen wir mit der Auflistung der Volumen unseres OpenStack-Projekts:
openstack volume list
In der Liste der ausgegebenen Volumen sollten Sie eines mit dem Namen Ihrer virtuellen Maschine sehen, gefolgt von -sda (bzw. sdb, sdc usw., wenn Ihre VM über mehrere Festplatten verfügt). Genau dieses Volumen ist für uns von Interesse.
Kopieren Sie dessen ID (Spalte ID in der Rückgabe des vorherigen Befehls) und geben Sie den folgenden Befehl ein:
openstack server create --flavor a2-ram4-disk0 –volume --network ext-net1
Ihre Instanz wird nun gestartet 😊 Sie können über die VNC-Konsole überprüfen, ob alles ordnungsgemäss funktioniert, indem Sie die URL, die über folgenden Befehl angezeigt wird, in Ihren Browser eingeben:
openstack console url show
Sie können sich auch über das übliche Protokoll (SSH, RDP usw.) mit dieser verbinden. Achten Sie aber darauf, dass Sie die erforderlichen Ports in Ihrer Sicherheitsgruppe geöffnet haben.
6. Besonderheit der Public Cloud von Infomaniak
Bei der Public Cloud von Infomaniak gibt es eine kleine Besonderheit, um das soeben erstellte Volumen zum Laufen zu bringen. Bei der Erstellung unseres Volumens fügt virt-v2v automatisch Metadaten zu unserem Volumen hinzu. Mit Letzteren kann angegeben werden, wie die virtuelle Maschine konfiguriert werden soll, die unser Volumen im Hypervisor verwendet. Einige werden jedoch nicht in allen Regionen der Plattform (Region dc3-a) unterstützt.
Um dies zu korrigieren, muss nur die Eigenschaft entfernt werden, die aktuell nicht mit der Plattform kompatibel ist. Die entsprechende Eigenschaft lautet hw_machine_type=q35
. Folglich entfernen wir die Eigenschaft unseres Volumens mit folgendem Befehl:
openstack volume unset --image-property hw_machine_type
Danach können Sie Ihre Instanz wie oben beschrieben mit der Funktion boot from volume der Plattform starten.
Mehr erfahren
- Public Cloud von Infomaniak entdecken
- Warum OpenStack für seine Public Cloud wählen
- Funktionsweise der unabhängigen Cloud von Infomaniak entdecken
Kevin Allioli ist Cloud- und Systemarchitekt bei Infomaniak und OpenStack- und AWS-Experte. Mit seinen mehr als zehn Jahren Cloud-Computing-Erfahrung trägt er zur Entwicklung der Public Cloud von Infomaniak bei.
Fallstudie: RGOODS entwickelt internationale NGO-Shops mit Cloud-Lösungen von Infomaniak
Donnerstag 28 März 2024