vSphere zu Proxmox: was wirklich mitgeht

Jede Anleitung zum Verlassen von VMware beginnt mit der Festplatte, denn die Festplatte ist der Teil, der eine Datei hat. VMDK umwandeln, importieren, starten, fertig.

Die Festplatte ist der leichte Teil. Was eine vSphere-Maschine funktionieren lässt, sitzt an vier anderen Stellen, von denen keine im VMDK liegt: wie die Plattform die Maschine identifiziert, wie der Gast beim ersten Start konfiguriert wird, für welche virtuelle Hardware der Gast Treiber hat und welcher Agent im Gast Fragen über ihn beantwortet. Jedes davon ist auf Proxmox ein anderes Problem, und nur eines meldet sich, wenn es schiefgeht.

Das haben wir beim Bauen von Lese- und Schreibwegen gegen beide gefunden, gemessen gegen vCenter 6.7.0 build-24323669.

Die Festplatte, und der eine Aufruf, den es nicht gibt

Es sind zwei Formen virtueller Festplatten im Spiel. Eine laufende vSphere-VM hat ein flaches VMDK plus einen kleinen Deskriptor. Ein OVA oder ein heruntergeladenes Cloud-Image hat ein stream-optimized VMDK: komprimiert, sequenziell und so, wie es ist, nicht startfähig.

Der naheliegende Weg zur Umwandlung ist CopyVirtualDisk_Task mit einer Zielspezifikation, die das Zielformat nennt. Diesen Aufruf gibt es auf einem eigenständigen ESXi-Host, und auf vCenter gibt es ihn nicht: Er antwortet „The requested operation is not implemented by the server“. Das ist ein gutes Beispiel für eine breitere Falle in dieser API, in der dieselbe Operation auf einer Verwaltungsebene existiert und auf einer anderen nicht.

Zwei Dinge funktionieren, und man sollte sie in dieser Reihenfolge kennen:

• CopyVirtualDisk_Task ohne Zielspezifikation funktioniert auf vCenter 6.7 und kopiert eine Festplatte unter Beibehaltung ihres Typs. Auf diesem vCenter verlangt er das Argument datacenter; die Form mit nur einem Datastore-Pfad wird abgelehnt.
• Der OVF-Importweg (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) nimmt eine stream-optimized Festplatte an und wandelt sie beim Hineinschreiben um. Er braucht nur den .ovf-Deskriptor, nicht das ganze OVA: Ein OVA ist ein tar-Archiv mit dem Deskriptor vorne, abrufbar mit einer einzigen Range-Anfrage über 128 kB.

Auf der Proxmox-Seite ist das Gegenstück qm disk import, das ein VMDK nimmt und es im eigenen Format des Zielspeichers dorthin schreibt. Dieser Teil ist wirklich unkompliziert.

Die Bereitstellung ist auf beiden Seiten unterschiedlich modelliert. vSphere hat zwei Flags, thinProvisioned und eagerlyScrub, und die sind keine Auswahl aus dreien: thin schließt eager aus, gültig sind also thin, thick lazy zeroed und thick eager zeroed. Alles, was das als ein Enum mit vier Werten modelliert, schickt irgendwann eine unmögliche Kombination.

Identität: die ID, die Sie haben, ist keine Identität

Das beißt Monate später, nicht am Umzugstag.

Ein vSphere-Objekt wird über eine Managed Object Reference adressiert, etwas wie vm-101. Das sieht aus wie eine ID und ist keine: Es ist ein Schlüssel in der Datenbank genau dieses vCenters. Bauen Sie diese Datenbank neu auf oder stellen Sie sie wieder her, folgt die Referenz der Maschine nicht, und sie wird erneut vergeben, an eine andere VM. Was Sie vor sechs Monaten gespeichert haben, zeigt jetzt auf die Maschine von jemand anderem, und die Operation, die Sie gleich ausführen wollten, ist ein Ausschalten.

Die haltbare Kennung ist config.instanceUuid. Speichern Sie die, und lösen Sie die Referenz je Operation über FindByUuid auf.

Proxmox hat die entgegengesetzte Form. Eine VM ist eine vmid: stabil, für Menschen lesbar, in jedem Befehl sichtbar, eindeutig je Cluster. Damit lässt sich angenehmer arbeiten, und es hat seine eigene Folge für einen Umzug. Sie wählen neue Identitäten, jedes externe System, das eine Maschine über ihre vSphere-Kennung ansprach, muss also neu ausgerichtet werden.

Auch das Modell des Orts unterscheidet sich. Mit aktiviertem DRS wechselt der Host, auf dem eine VM läuft, ohne dass jemand fragt, ein Klon bekommt also einen Ressourcen-Pool und vSphere wählt. Auf Proxmox ist der Node die Einheit, und ein Wechsel zwischen Nodes ist ausdrücklich. Ein Inventar, das für einen DRS-Cluster „welcher Host“ festhielt, hat etwas festgehalten, das sich von selbst ändert.

Gastanpassung ist ein anderer Mechanismus, keine andere Syntax

Beide Plattformen können einen Gast beim ersten Start konfigurieren. Sie tun es auf Wegen, die keinen Code teilen.

Auf vSphere ist der Weg, der ohne Abhängigkeit vom Gast funktioniert, guestinfo: vier Schlüssel in extraConfig, gelesen von der VMware-Datenquelle von cloud-init.

Die .encoding-Schlüssel sind nicht optional. Lassen Sie sie weg, liest cloud-init den base64-Text als den Inhalt selbst, und die Maschine kommt mit einem vierzig Zeichen langen Unsinns-Hostnamen hoch. Kein Fehler, nur eine falsche Antwort.

Die Alternative, das eigene CustomizeVM_Task von VMware, braucht VMware Tools im Gast und auf älteren Linux-Vorlagen ein funktionierendes perl, und das ist die Art Anforderung, die man entdeckt, wenn ein Bereitstellungslauf auf halbem Weg hängen bleibt.

Auf Proxmox ist die Anpassung ein an die VM gehängtes cloud-init-Laufwerk, konfiguriert über eine kleine Menge Schlüssel: ipconfig0 bis ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Einer davon hat eine Falle, die unsichtbar bleibt, bis ein Kunde sich beschwert. ciupgrade hat im Proxmox-Schema default = 1, ihn wegzulassen bedeutet also nicht „beim ersten Start keine Pakete aktualisieren“, sondern „aktualisieren“. Ein nicht angehaktes Kästchen muss als ausdrückliches ciupgrade=0 gesendet werden, sonst lügt das Kästchen. Vor PVE 8.1 gibt es ihn außerdem nicht, dort ist es ein harter Fehler, ihn überhaupt zu senden, und kein ignorierter Schlüssel.

Zwei weitere Dinge gehen auf beiden Seiten gleich schief. Die Instanz-ID muss sich ändern, wenn eine Maschine eine neue Identität bekommt: Das iid-local01 aus den meisten Beispielen bedeutet, dass eine geklonte Maschine die Konfiguration der Vorlage behält. Und die Schnittstelle wird nicht den Namen haben, den Sie erwarten: ens160 auf VMware, etwas anderes auf KVM. Netplan mit match: {name: "e*"} statt eines geratenen Gerätenamens ist das, was ein Image auf beiden funktionieren lässt.

Virtuelle Hardware, für die der Gast Treiber hat

vmxnet3 ist die vernünftige Voreinstellung für die Netzwerkkarte auf VMware, und sie hat eine Voraussetzung: Sie braucht VMware Tools im Gast. Installieren Sie eine Vorlage ohne Tools, geben Sie ihr eine vmxnet3-Karte, und das Betriebssystem sieht überhaupt keine Netzwerkkarte.

Das zählt zweimal. Davor, weil eine Vorlage, die auf ESXi gut startet, vielleicht e1000e braucht. Und danach, weil die leistungsstarke Wahl von Proxmox virtio ist, das eigene Treiber braucht: in modernem Linux vorhanden, in einem Windows-Standardimage absolut nicht. e1000 ist auf beiden Plattformen die langsame, langweilige, überall funktionierende Möglichkeit, und für eine Maschine, die Sie umziehen, ist es der richtige erste Start.

Der Disk-Controller hat dieselbe Form von Problem: Auf Proxmox ist der schnelle Weg virtio-scsi, und das ist wieder eine Treiberfrage. Wir haben nicht gemessen, was ein Wechsel des Controllertyps mit einem bereits installierten Gast macht, und es ist eine häufige Ursache für eine Maschine, die sauber umzieht und danach nicht startet.

Der Agent im Gast heißt anders

Ein überraschender Teil dessen, was ein Panel anzeigt, kommt gar nicht vom Hypervisor.

Auf vSphere kommt guest.ipAddress von VMware Tools. Ebenso die echte Plattenbelegung, über guest.disk: Der Wert summary.storage.committed auf Datastore-Ebene ist die Bereitstellungszahl und liest sich für eine Thin-Disk falsch. Laufen die Tools nicht, sind diese Felder leer, und leer heißt „ich weiß es nicht“, nie „die Maschine hat keine Adresse“.

Nach dem Umzug kommt dieselbe Information von qemu-guest-agent, einem anderen Paket mit einem anderen Namen, das installiert werden muss. Eine Flotte, die ohne ihn umzieht, sieht in Ihrem eigenen Inventar aus wie eine Flotte, die ihre Adressen verloren hat.

Eine weitere Warnung zu dieser Adresse: Sie kommt über den eigenen Kanal des Hypervisors zum Gast und nicht über das Netz. Sie kann für eine Maschine, deren Karte an nichts hängt, völlig zutreffend sein. Das Einzige, was Erreichbarkeit beweist, ist, sie zu erreichen.

Netzwerk, und die Verbindung, die still keine ist

vSphere hat zwei Arten von Netzanbindung, und sie sehen nicht gleich aus. Ein Standard-Network wird über den Namen referenziert; eine DistributedVirtualPortgroup über die UUID ihres Switches plus ihren eigenen Portgruppen-Schlüssel.

Bauen Sie nur die erste Form, bekommen Sie in jeder Umgebung mit einem verteilten Switch eine Karte, die an nichts hängt. vCenter lehnt das nicht ab, denn der Name existiert ja als Netzobjekt. Die Maschine startet ohne Verbindung, und der Fehler steckt im Gast.

Proxmox ist einfacher: Eine NIC nennt eine Bridge, mit einem optionalen VLAN-Tag. Die Zuordnung müssen Sie selbst schreiben; es gibt keine automatische Übersetzung von einer Portgruppe zu einer Bridge. Zwei weitere Dinge sind vor dem ersten Umzug zu entscheiden:

• MAC-Adressen. Sie mitzunehmen hält DHCP-Reservierungen und Lizenzbindungen gültig und heißt, dass zwei Maschinen sich eine MAC teilen, falls die Quelle je wieder eingeschaltet wird. Entscheiden Sie ausdrücklich.
• Die Firewall je VM. vSphere hat keine; das ist NSX, ein eigenes Produkt. Proxmox hat eine. Maschinen, die von VMware kommen, hatten nie eine Firewall auf Hypervisor-Ebene, und eine einzuschalten ist ein Projekt und kein Häkchen.

Was nicht mitreist und in keiner Datei steht

Manches hat kein Gegenstück, und ein Plan, der es nicht benennt, entdeckt es Stück für Stück:

• Snapshots. Die Maschine geht als flache Festplatte hinüber; ein Snapshot-Baum ist eine vSphere-Struktur, und es gibt nichts, worin man ihn importieren könnte.
• Changed Block Tracking, und damit jede inkrementelle Backup-Historie, die darauf beruhte.
• Tags, benutzerdefinierte Attribute und Ordner. Die leben in der Datenbank von vCenter und nicht auf der Maschine.
• Ressourcen-Pools, DRS-Regeln, Reservierungen und Shares. Proxmox hat keinen entsprechenden Scheduler, aus einer als DRS-Regeln geschriebenen Platzierungsrichtlinie werden also Entscheidungen darüber, auf welchem Node eine Maschine sitzt.
• VM-Hardwareversion. Ein vSphere-Begriff ohne Gegenstück auf Proxmox, alles in Ihrer Automatisierung, was daran hängt, ist jetzt toter Code.

Was unser eigenes Werkzeug tut und was nicht

Ganz deutlich: Wir haben keine Migration von vSphere nach Proxmox gebaut. Unser Migrationswerkzeug deckt heute genau einen Weg ab, zwischen zwei Gamepanels, und er sitzt hinter einem Feature-Schalter, der aus ist.

Zwei Regeln aus dem Bau dieses einen Wegs lohnen sich trotzdem zum Abschauen, denn sie machen eine Migration prüfbar statt hoffnungsvoll. Die Quelle ist schreibgeschützt, als Konstante und nicht als Schalter, es gibt also keine Konfiguration, in der das Werkzeug auf das System schreibt, das Sie verlassen. Und ein Trockenlauf ist vor einer Anwendung Pflicht, mit einer Zählung je Kategorie danach, Quelle gegen Ziel. Eine Migration, die Ihnen nicht sagen kann, wie viele Maschinen sie bewegt hat, ist nicht fertig; sie hat aufgehört.

Das entstand beim Bauen der vSphere- und Proxmox-Integrationen für Provibr, ein Server-Management-Panel für Hosting-Anbieter, wo beide Hypervisoren durch eine Oberfläche lesbar sein müssen, ohne dass einer als der andere beschrieben wird. Die Einrichtungsnotizen stehen in der vSphere- und der Proxmox-Dokumentation.