Performance ESXi Importer

[einhirn]

Das wundert mich. Normalerweise wird das Netzwerk immer angezeigt, da es in der .vmx steht. Eventuell ist die Benamung im ESXi unschön gewählt.

Bei mir steht in der vmx sowas drin wie "distributed-portgroup-12341342" - wir haben einen Distributed vSwitch - vielleicht ist das etwas, was vom Importer noch nicht vorgesehen ist. Andererseits haben wir halt, wie in vSphere üblich, Portgroups mit verschiedenen Namen - und unter Proxmox mit einer VLAN-Aware Linux Bridge nur den VLAN-Tag. Ich habe hin und her überlegt, ob es besser wäre, auf die VLAN-Awareness zu verzichten und stattdessen ca. 60-90 Bridges anzulegen, die jeweils nur ein VLAN enthalten, aber es scheint mir so, als ob das weniger hypsch ist - jedenfalls wird die VLAN-Awareness immer als großer Vorteil gelobt...

Da der Treiber eh nur Read sauber kann, hättest du die LUNs Readonly mounten müssen. Da hätte es auch keine SCSI Reservation Probleme gegeben.

Jein - einerseits hab ich noch keinen Weg gefunden, wie ich dafür sorge, dass jegliche Writes und ähnliche Kommandos (set reservation, clear reservation) auf eine LUN clientseitig blockiert werden (ich fürchte fast, das sowas in "open-iscsi" nicht vorgesehen ist) - andererseits bin ich mir nicht sicher, ob das nicht dazu führen würde, dass das "vmfs6-tool" das Dateisystem nicht öffnen mag.

Ein Workaround war, einen Writable Snapshot des VMFS auf dem Storage anzulegen - allerdings müsste man vorher halt die jeweilige VM abgeschaltet haben und dann mit Iscsi-Rescans etc. rumfummeln - erscheint nicht so, als könnte es dazu dienen, die Downtime nachhaltig zu reduzieren - entweder muss ich das für jede VM einzeln machen (viel Fummelei) oder ich muss z.B. 10 VMs auf einmal abschalten, Snapshot, Import etc. Auch doof.

Also per Storage-vMotion im laufenden Betrieb auf NFS migrieren, dort abschalten und in Proxmox die VM wieder anreißen. Jetzt fehlt mir nur noch die Anleitung, wie ich die Erstellung der "VM-Hüllen" am besten vornehme. Ich habe in einem anderen Thread von "der Harry" ein paar Scriptschnipsel gefunden, aber afaik bisher noch nichts, was das Verhalten des Importers (übernimm die Mac-Adresse und die BIOS UUID etc.) nachahmt. Immerhin ist der Importer (naja, das GUI) nur Perl-Code, vielleicht kann ich da auch was reinpfuschen oder herauslesen.

 

[Falk R.]

Bei mir steht in der vmx sowas drin wie "distributed-portgroup-12341342" - wir haben einen Distributed vSwitch - vielleicht ist das etwas, was vom Importer noch nicht vorgesehen ist. Andererseits haben wir halt, wie in vSphere üblich, Portgroups mit verschiedenen Namen - und unter Proxmox mit einer VLAN-Aware Linux Bridge nur den VLAN-Tag. Ich habe hin und her überlegt, ob es besser wäre, auf die VLAN-Awareness zu verzichten und stattdessen ca. 60-90 Bridges anzulegen, die jeweils nur ein VLAN enthalten, aber es scheint mir so, als ob das weniger hypsch ist - jedenfalls wird die VLAN-Awareness immer als großer Vorteil gelobt...

Baue dir ein SDN mit VLAN Portgroups, das funktioniert wie bei dvSwitch von VMware, nur mit weniger klicks.
Ja die Distributed Portgroups sind nicht klartext lesbar und werden nicht über die API aufgelöst, da der ESXi keine Infos über den Switch hat. Migration über das vCenter ist aber noch langsamer, daher auch keine gute Option.

Jein - einerseits hab ich noch keinen Weg gefunden, wie ich dafür sorge, dass jegliche Writes und ähnliche Kommandos (set reservation, clear reservation) auf eine LUN clientseitig blockiert werden (ich fürchte fast, das sowas in "open-iscsi" nicht vorgesehen ist) - andererseits bin ich mir nicht sicher, ob das nicht dazu führen würde, dass das "vmfs6-tool" das Dateisystem nicht öffnen mag.

Ein Workaround war, einen Writable Snapshot des VMFS auf dem Storage anzulegen - allerdings müsste man vorher halt die jeweilige VM abgeschaltet haben und dann mit Iscsi-Rescans etc. rumfummeln - erscheint nicht so, als könnte es dazu dienen, die Downtime nachhaltig zu reduzieren - entweder muss ich das für jede VM einzeln machen (viel Fummelei) oder ich muss z.B. 10 VMs auf einmal abschalten, Snapshot, Import etc. Auch doof.

Also per Storage-vMotion im laufenden Betrieb auf NFS migrieren, dort abschalten und in Proxmox die VM wieder anreißen. Jetzt fehlt mir nur noch die Anleitung, wie ich die Erstellung der "VM-Hüllen" am besten vornehme. Ich habe in einem anderen Thread von "der Harry" ein paar Scriptschnipsel gefunden, aber afaik bisher noch nichts, was das Verhalten des Importers (übernimm die Mac-Adresse und die BIOS UUID etc.) nachahmt. Immerhin ist der Importer (naja, das GUI) nur Perl-Code, vielleicht kann ich da auch was reinpfuschen oder herauslesen.

Ich bin leider nicht begabt was scripten angehtm, daher habe ich das immer per Hand (schon einige hundert mal) gemacht. Wenn jemand mit Ahnung zum Scripte schreiben mit mir verabreden möchte, Ich würde gern etwas Automatisation erarbeiten.

 

[einhirn]

[...Distributed Port Groups...] Migration über das vCenter ist aber noch langsamer, daher auch keine gute Option.

Hmm - ich hatte das aber doch in Erwägung gezogen, da der "(Live-)Import" über die von Proxmox erstellten virtuellen Dateisystemgeschichten ohnehin nicht taugt. Dann würde ich über den vCenter nur die Infos der VMs beziehen und die VMDKs per NFS heranholen. Kann sogar sein, dass ich dann mit einem einzigen "Bind"-Mount auskomme, weil die VMs dann ja alle in einem Datastore zu liegen kommen werden. Solange der Fuse-mount nicht ab und an neu angezogen wird, so dass mein Bind-Mount "übermounted" wird...

Das Ding mit dem SDN sieht aber erstmal so aus, wie ich es auch manuell bauen würde - vor allem gibts wieder eine Beschränkung auf sogar nur 8 Zeichen im Netzwerknamen - unser aktuelles Namensschema enthält allerdings IP-Subnet, VLAN-Tag und Kurzbeschreibung. Das passt nicht in 8 Zeichen.

Beim Scripten hatte ich bisher wie gesagt nur hier und da Schnippsel gefunden, nichts, was den Umfang (und evtl. Komfort) des Import-Dialogs ersetzen würde.

/usr/libexec/pve-esxi-import-tools/list-vms.py

ist vermutlich das Script, mit denen die "Manifest.JSON"-Dateien geschrieben werden

/usr/share/perl5/PVE/Storage/ESXiPlugin.pm

Ist das Plugin für den ESXi-"Storage" - vielleicht kann ich da ja herauslesen, wo die Daten für den Import-Dialog zusammengesucht werden bzw. das Importkommando selbst gestrickt wird.

Ein Hinweis von irgendwo hier aus dem Forum zum Thema "Aufzeichnung von Kommandos" war: Webentwickler-Tools im Browser verwenden - und ja, da habe ich dann auch folgende URLs bekommen:

https://proxmox-server:8006/api2/extjs/nodes/proxmox-server/storage/esx-server/import-metadata?volume=ha-datacenter%2Fdatastorename%2Fvmname%2Fvmname.vmx

Liefert als JSON-Objekt alles, was man über die VM wissen will - alles, was auch im Dialog landet.

https://proxmox-server:8006/api2/extjs/nodes/proxmox-server/qemu

wird dann beim Knopfdruck auf "Import" aufgerufen, mit Parametern:

sockets=4&
name=vmname&
scsihw=pvscsi&
memory=6144&
smbios1=uuid%3D423922aa-27d9-c070-fc46-da5b75524907&
bios=seabios&
boot=order%3Dide0%3Bscsi0%3Bscsi1&
ostype=l26&
vmid=120&
cores=1&
cpu=Broadwell-noTSX&
scsi0=iSCSI-Datatstore%3A0%2Cimport-from%3Desx-server%3Aha-datacenter%2Fdatastore%2Fvmname%2Fvmname.vmdk&
scsi1=iSCSI-Datatstore%3A0%2Cimport-from%3Desx-server%3Aha-datacenter%2Fdatastore%2Fvmname%2Fvmname_1.vmdk&
net0=vmxnet3%3D00%3A50%3A56%3Ab9%3A7f%3A60%2Cbridge%3Dvmbr0%2Ctag%3D15&
ide0=file%3Dnone%2Cmedia%3Dcdrom&
live-restore=1'

(Zeilenumbrüche nach jedem '&' für die Leserlichkeit...)

Ich schaue mal, ob ich daraus eine Automatisierung basteln kann, die dann entweder den Live-Restore direkt von einem anderen Proxmox-Storage machen kann oder, nach meinen Erfahrungen eher sinnvoll, einfach ein VMDK vom NFS direkt anhängt.

 

[Falk R.]

Beim SDN Namen gibst du eine kurze ID an. Den langen Namen packst du in die Description. Wird in der GUI zusammen angezeigt und die ID eignet sich besser zum scripten.

 

[einhirn]

Ich schaue mal, ob ich daraus eine Automatisierung basteln kann, die dann entweder den Live-Restore direkt von einem anderen Proxmox-Storage machen kann oder, nach meinen Erfahrungen eher sinnvoll, einfach ein VMDK vom NFS direkt anhängt.

Es wäre bestimmt sauberer und lesbarer in Python. Aber irgendwie ist es für mich einfacher das ganze in Bash zu verbrechen, als erst eine Python-Umgebung zu erstellen...

#!/usr/bin/bash

# Name der zu importierenden VM
VMNAME="VM-NAME"
# VLAN-Tag für die vlan-Aware-Bridge
# FIXME Bridge-Name noch hardgecoded.
VLAN_TAG="1309"
# PVE_NODE-Name
PVE_NODE="proxmox-Host"
# Name des ESXi-Storage in Proxmox
ESXI_NAME="esxi-import-storage"
# vSphere Datastore-Name
DATASTORE_NAME="vsphere-datastore-name"
# Prefixe und Namen für den (vSphere-) NFS-Storage-Mount auf dem PVE-Host
DATASTORE_PATHPREFIX="nfstemp"
PVE_STORAGENAME="local-bckp"
PVE_STORAGEPATHPREFIX="/mnt/pve"

# Rufe die Konfigurationsdaten von VMware ab
IMPORT=$(curl -s -k -H @curl-mox-api-token.txt https://localhost:8006/api2/json/nodes/$PVE_NODE/storage/$ESXI_NAME/import-metadata?volume=ha-datacenter%2F${DATASTORE_NAME}%2F${VMNAME}%2F${VMNAME}.vmx)

# Debug-Ausgabe
echo $IMPORT | jq .

# nächste freie VM-ID ermitteln
VMID=$(curl -s -k -H @curl-mox-api-token.txt https://localhost:8006/api2/json/cluster/nextid | jq -r '.data')

echo $VMID

# Konfiguration für den API-Call umformatieren, VLAN-Tag und PVE-Zielstorage konfigurieren
# FIXME: CPU-Typ etc. anpassen
VMCONFIG=$(echo $IMPORT | jq -r --arg tag $VLAN_TAG --arg pve_storagename $PVE_STORAGENAME --arg vmid $VMID '.data| ."create-args".name as $name | [("vmid="+$vmid),(."create-args" |to_entries | .[] | .value |= (. | tostring) | map_values(select(contains("media=cdrom")) |= "file="+.)| .key+"="+(.value | tostring | @uri)), (.net | to_entries | .[] |.value |= (.model +"="+.macaddr+",bridge=vmbr0,tag="+$tag |@uri)|.key+"="+.value),(.disks | to_entries |.[] |.key+"="+ ($pve_storagename + ":" + $vmid + "/" + (.value.volid | rindex($name) as $ind | .[$ind:]) + ",discard=on,iothread=1,ssd=1"|@uri ) ) ] | join("&") ')

# Debug-Ausgabe
echo $VMCONFIG

# Folgendes geht nur "lokal", daher oben auch "localhost" festgezurrt:

# Verzeichnis für Disk-Images der neu zu erstellenden Proxmox-VM erstellen und hinein wechseln
mkdir -v ${PVE_STORAGEPATHPREFIX}/${PVE_STORAGENAME}/images/${VMID}
cd ${PVE_STORAGEPATHPREFIX}/${PVE_STORAGENAME}/images/${VMID} || exit 1

# VMDK-"Disk Databases" von VMWare lesen und Kopie mit passendem Namen und angepasstem Pfad zu den "Daten-Dateien" hier ablegen
for f in ../../${DATASTORE_PATHPREFIX}/${VMNAME}/${VMNAME}.vmdk ../../${DATASTORE_PATHPREFIX}/${VMNAME}/${VMNAME}_[0-9].vmdk; do sed "s#\(.*\"\)\(.*.vmdk\"\)#\1${f%/*}/\2#" $f > ${f##*/}; done;

# Debug-Ausgabe
grep . *vmdk

# Zurück ins vorige Verzeichnis
cd -

# API-Call um die Proxmox-VM mit obiger Konfiguration anzulegen
echo $VMCONFIG | curl -sS -k -H @curl-mox-api-token.txt https://localhost:8006/api2/json/nodes/mox01/qemu --data @-

# FIXME Migration der Daten von vmdk zu Proxmox-Format automatisch anstoßen

echo

Der Api-Token kann über die GUI erstellt werden, dabei muss entweder "Privilege Separation" abgehakt werden, oder dem Token in der Rechtevergabe alles nötige eingeräumt werden. Die Datei für cURL folgt dem Schema:

Authorization: PVEAPIToken=root@pam!ALIAS=00000000-0000-0000-0000-000000000000

Gibt, wie gesagt, noch einige FIXMEs und auch der "jq"-Code kann bestimmt noch optimiert oder schöner formatiert werden, aber zwei oder drei VMs habe ich damit schon übernehmen können.