Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
XVA ist das native Exportformat von XenServer. Wenn Sie zu VMware wechseln, erkennt ESXi dieses Format nicht – Sie müssen es zuerst in VMDK umwandeln. Dieser Leitfaden erläutert vier Umsetzungsmethoden sowie die Lösungen für Boot- und Treiberprobleme, die nach einer Migration häufig auftreten.
Eine XVA-Datei ist das standardisierte Exportformat für Citrix XenServer und XCP-ng. Es bündelt die VHD-Festplatten der virtuellen Maschine sowie eine XML-Konfigurationsdatei in einem einzigen Tar-Archiv.
VMDK ist das virtuelle Festplattenformat von VMware. ESXi und vSphere benötigen dieses Format zum Ausführen virtueller Maschinen. Zusammen mit ihm wird eine VMX-Datei als Konfigurationsdatei verwendet, die die Hardwareeinstellungen der virtuellen Maschine definiert.
Da XVA ein gepacktes Archiv und VMDK ein flaches Festplattenabbild ist, kann VMware eine XVA-Datei weder einbinden noch booten. Die Umwandlung des Festplattenformats ist die einzige Möglichkeit, eine XenServer-VM unter ESXi lauffähig zu machen.
Diese Formatumwandlung kommt vor allem bei Plattformmigrationen, Rechenzentrumskonsolidierungen und Notfallwiederherstellungsumgebungen vor, in denen an zwei Standorten unterschiedliche Hypervisoren betrieben werden.
Erfolgreiche Migrationen hängen stärker von der Vorbereitung der Quell-VM ab als vom Umwandlungstool selbst. Das Auslassen dieser Schritte führt oft zu nicht bootfähigen Systemen oder dem Fehler „Inaccessible Boot Device“.
Diese manuelle Methode für Linux-Benutzer umfasst das Entpacken des XVA-Archivs und das erneute Erstellen des Festplattenabbilds aus den einzelnen Komponenten. Dieser Ansatz bietet maximale Kontrolle und eignet sich hervorragend für XCP-ng oder eigenständige XenServer-Hosts.
Beginnen Sie auf dem XenServer-Host und erstellen Sie zuerst ein Raw-Festplattenabbild, bevor Sie Einstellungen auf der VMware-Seite vornehmen.
Schritt 1: VM aus XenServer exportieren: Führen Sie den folgenden Befehl direkt auf dem XenServer- oder XCP-ng-Host aus, um die VM als .xva-Datei zu exportieren.
sudo yum install qemu-img
Schritt 2: XVA-Archiv entpacken: XVA-Dateien sind Tar-Archive mit 1 MB großen Festplattenblöcken. Entpacken Sie den Inhalt in ein Arbeitsverzeichnis.
mkdir xva_out && tar -xf vm.xva -C xva_out
Schritt 3: Raw-Festplattenabbild neu erstellen: Verwenden Sie xva-img, um die entpackten Blöcke zu einem einzigen Raw-Festplattenabbild zusammenzufügen. Die Blöcke liegen in einem Unterverzeichnis mit dem Festplattenbezugnamen, z. B. Ref:1.
xva-img -p disk-export xva_out/Ref\:1/ vm.raw
Schritt 4: Raw-Abbild prüfen: Bestätigen Sie die korrekte Erstellung der Ausgabedatei, bevor Sie fortfahren.
qemu-img info vm.raw
Schritt 5: Raw-Abbild zu VMDK umwandeln: Nutzen Sie qemu-img, um aus dem Raw-Abbild eine VMDK-Datei zu erstellen.
qemu-img convert -f raw -O vmdk vm.raw output.vmdk
Sobald das VMDK bereit ist, wechseln Sie zur VMware-Umgebung für die restlichen Schritte.
Schritt 6: Upload zu VMware: Übertragen Sie die .vmdk-Datei mit dem vSphere-Client oder SCP auf Ihren ESXi-Datenspeicher. Erstellen Sie anschließend eine neue VM und wählen Sie Vorhandene virtuelle Festplatte verwenden, um die Datei anzuhängen.
XenConvert ist ein älteres Citrix-Tool zum Umwandeln virtueller Geräte zwischen verschiedenen Formaten. Es wird zwar nicht mehr aktiv weiterentwickelt, ist aber für Windows-Administratoren mit Vorliebe für grafische Oberflächen statt Kommandozeile eine Alternative.
Für diesen Ablauf ist XenConvert Version 2.3.1 oder 2.3.2 erforderlich. Ab Version 2.4 wurde die Unterstützung für die XVA-zu-OVF-Umwandlung entfernt, wodurch diese Versionen für diese Migrationsmethode ungeeignet sind.
Exportieren Sie zuerst die VM aus XenServer und wandeln Sie sie mit XenConvert in eine nutzbare Festplattendatei um.
xe vm-export vm=<VM_NAME> filename=vm.xva
Bevor Sie die Festplatte importieren, ist eine manuelle Änderung der Beschreibungsdatei erforderlich, um Boot-Fehler unter VMware zu verhindern.
qemu-img convert -f vpc -O vmdk input.vhd output.vmdkddb.adapterType = "lsilogic"Nach der Korrektur der Beschreibungsdatei kann die Festplatte hochgeladen und an eine neue VM angehängt werden.
Das OVA-Format (Open Virtualization Appliance) ist oft die effizienteste Möglichkeit, VMs zwischen verschiedenen Hypervisoren zu übertragen. Da sowohl Citrix als auch VMware den OVF-Standard unterstützen, benötigt diese Methode kein separates V2V-Konvertierungstool.
Der erste Schritt besteht darin, eine OVA-Datei aus Ihrer vorhandenen XenServer- oder XCP-ng-Umgebung zu erstellen.
Sobald die OVA-Datei erstellt ist, läuft der restliche Vorgang vollständig in vSphere ab.
Diese Methode unterscheidet sich von manuellen Exportverfahren, da sie eine laufende VM direkt über das Netzwerk umwandelt – es ist kein XVA-Export oder die Verarbeitung separater Festplattendateien erforderlich. Der Ablauf ähnelt der VMware P2V-Migration, bei der Converter die Übertragung und Formatumwandlung automatisch übernimmt.
Prüfen Sie vor dem Start des Umwandlungsauftrags folgende zwei Bedingungen.
Diese Methode erfordert eine stabile Netzwerkverbindung zwischen dem XenServer-Host und dem Ziel-ESXi-Host bzw. vCenter. VMware vCenter Converter Standalone muss zudem auf einem Windows-Rechner installiert sein, der beide Umgebungen erreichen kann.
Wenn alle Voraussetzungen erfüllt sind, öffnen Sie Converter und folgen Sie diesen Schritten zum Start der Migration.
Nach Abschluss der Migration installieren Sie VMware Tools im Gastbetriebssystem. Falls XenServer-Tools nicht zuvor deinstalliert wurden, entfernen Sie diese vor der Installation von VMware Tools.
Auch bei einer fehlerfreien Umwandlung kann eine migrierte VM nicht booten oder schlechte Leistungen erzielen. Die meisten Probleme entstehen durch Unterschiede in der Verwaltung von Speichercontrollern und Gerätetreibern zwischen XenServer und VMware.
Dies wird in der Regel durch einen nicht übereinstimmenden SCSI-Controller verursacht. Überprüfen Sie zuerst die .vmdk-Beschreibungsdatei: Öffnen Sie die kleinere der beiden .vmdk-Dateien mit einem Texteditor und bestätigen Sie die korrekte Einstellung des Adaptertyps:
ddb.adapterType = "lsilogic"
Wenn die Beschreibungsdatei korrekt ist und die VM trotzdem nicht bootet, ändern Sie den Festplattencontrollertyp in den VM-Einstellungen auf LSI Logic SAS oder LSI Logic Parallel und versuchen Sie den Bootvorgang erneut.
Das Gastbetriebssystem erkennt nach dem ersten Boot ggf. keinen Netzwerkadapter, da VMware einen anderen virtuellen Netzwerkkarten-Typ (VMXNET3) verwendet als XenServer. Installieren Sie VMware Tools, um die passenden Netzwerktreiber bereitzustellen.
Wenn die VM bootet aber langsam läuft, prüfen Sie, ob noch XenServer-PV-Treiber oder Citrix-Komponenten installiert sind. Diese Treiber versuchen mit dem nicht mehr vorhandenen Xen-Hypervisor zu kommunizieren und verursachen unnötigen Systemaufwand. Deinstallieren Sie alle Xen- und Citrix-Komponenten und starten Sie neu.
Die in diesem Leitfaden vorgestellten Methoden eignen sich für einmalige Migrationen, erfordern jedoch viel manuelle Arbeit: Export von XVA-Dateien, Verarbeitung von Festplattenblöcken, Bearbeitung von Beschreibungsdateien und die Fehlerbehebung bei Boot-Problemen. Für Teams mit mehreren zu migrierenden VMs oder Produktionsmigrationen ohne Ausfallzeit ist eine spezialisierte Migrationsplattform die praktischere Lösung.
i2Migration ist eine vereinheitlichte Migrationsplattform für plattformübergreifende Workload-Übertragungen zwischen physischen, virtuellen und Cloud-Umgebungen. Es bewältigt die heterogenen Virtualisierungs-Migrationen wie in diesem Artikel beschrieben – einschließlich V2V-Szenarien zwischen unterschiedlichen Hypervisor-Plattformen – ohne manuelle Festplattenumwandlung oder Dateiverarbeitung.
Für Teams, die nach der Migration zudem dauerhaften Datenschutz benötigen, bietet i2Availability Echtzeit-Replikation und automatisches Failover zwischen Umgebungen – eine ideale Ergänzung, sobald Ihre VMs unter VMware laufen.
F1: Kann ich XVA zu VMDK ohne Linux umwandeln?
Ja. Das Windows-basierte Tool XenConvert (Version 2.3.1 oder 2.3.2) übernimmt die Umwandlung ohne Kommandozeilenbefehle. Alternativ ist der Export der VM als OVA-Datei aus XenCenter meist die einfachere Lösung – diese lässt sich direkt in vSphere importieren, ohne Festplatten bearbeiten zu müssen.
F2: Kann eine XVA mehrere Festplatten enthalten? Wie gehe ich damit um?
Eine XVA-Datei kann mehrere virtuelle Festplatten enthalten. Wenn Sie das Archiv mit tar entpacken, liegt jede Festplatte in einem eigenen Unterverzeichnis – Ref:1, Ref:2 usw. Führen Sie xva-img separat für jedes Verzeichnis aus, um einzelne Raw-Abbilder zu erstellen, wandeln Sie jedes zu VMDK um und hängen Sie alle Abbilder an die neue VM in vSphere an.
F3: Kann ich VMDK zurück zu XVA umwandeln?
Ja, der Vorgang ist jedoch keine einfache Ein-Schritt-Umkehrung. Exportieren Sie die VMware-VM als OVF oder OVA und verwenden Sie anschließend den Importassistenten in XenCenter, um sie zurück nach XenServer zu bringen. Der Import übernimmt die Festplattenformatumwandlung, danach müssen Sie VMware Tools entfernen und XenServer-Tools im Gastbetriebssystem neu installieren.
F4: Sollte ich statt manueller XVA-Umwandlung einfach OVA verwenden?
Ja, dies ist für die meisten Umgebungen die empfohlene Vorgehensweise. OVA ist ein branchenweiter Standard, der sowohl von XenServer als auch VMware unterstützt wird. Dadurch entfallen das manuelle Neuaufbauen von Festplatten oder das Bearbeiten von Beschreibungsdateien. Der einzige Nachteil: Ältere XenServer-Versionen unterstützen ggf. keinen OVA-Export – in diesem Fall ist die manuelle xva-img-Methode die Ausweichlösung.
Die Umwandlung von XVA zu VMDK ist selten ein einfacher Ein-Schritt-Vorgang. Die passende Methode hängt von Ihrer Umgebung und verfügbaren Tools ab: Die Linux-Kommandozeilenmethode bietet maximale Kontrolle, XenConvert und das OVA-Verfahren eignen sich gut für Windows-Workflows, vCenter Converter ist die beste Wahl für die Migration laufender VMs ohne Ausfallzeit.
Unabhängig von der gewählten Methode sind die Vorbereitungen ebenso wichtig wie die eigentliche Umwandlung. Das Deinstallieren von XenServer-Tools vor dem Export und die Korrektur des Festplattenadaptertyps danach sind die beiden entscheidenden Schritte für einen sauberen ersten Boot der VM.
Für Teams mit großen oder produktionsrelevanten Migrationsprojekten eliminiert i2Migration von Info2soft den größten Teil des manuellen Aufwands – es übernimmt plattformübergreifende V2V-Übertragungen, Treiberinjektion und Validierung automatisch, sodass Sie sich auf das Ergebnis der Migration statt auf die Handhabung von Tools konzentrieren können.
