Performance ESXi Importer

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.
 
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.
 
  • Like
Reactions: Johannes S
[...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.

Code:
/usr/libexec/pve-esxi-import-tools/list-vms.py
ist vermutlich das Script, mit denen die "Manifest.JSON"-Dateien geschrieben werden
Code:
/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:

Code:
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.

Code:
https://proxmox-server:8006/api2/extjs/nodes/proxmox-server/qemu
wird dann beim Knopfdruck auf "Import" aufgerufen, mit Parametern:

Code:
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.
 
  • Like
Reactions: waltar
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.
 
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...

Bash:
#!/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:
Code:
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.
 
Last edited:
Ich hatte mir das Script mal in Python umschreiben lassen von der ChatGPT-Maschinerie - inzwischen war ich auf die Methode umgeschwenkt, mir die VMDKs per SSHfs auf einen der Proxmox-Server zu holen um die neue VM erstmal zu starten und dann eine Live-Migration der Platten durchzuführen. Bei kritischen VMs denke ich aber, dass ich vermutlich doch noch auf Umkopieren (Storage-VMotion) auf einen gemeinsam nutzbaren NFS-Storage setzen würde - sicherheithalber.

Ein großes FIXME gibts noch - aktuell setze ich zum Abrufen der VM-Konfiguration noch auf den API-Call, der den Proxmox-eigenen Import-Mechanismus voraussetzt. Ich würde gerne stattdessen direkt an die VMWare-API gehen und mir die benötigten Daten da heraus holen. Würde vieles deutlich vereinfachen, denke ich.

Da wir aber aktuell mit vielen anderen Dingen beschäftigt sind hier, weiß ich noch nicht, wann ich dazu komme, mir das schreiben zu lassen und es dann nach Korrekturen in das Programm einzupflegen...

import-vmware-vm.py:
Python:
#!/usr/bin/env python3
import os
import requests
import json
import urllib.parse
import argparse

def read_api_token(file_path):
    with open(file_path, 'r') as f:
        line = f.readline().strip()
    key, value = line.split(': ', 1)
    return {key: value}

def read_config_file(config_file):
    if config_file:
        with open(config_file, 'r') as f:
            return json.load(f)
    return {}

def get_import_data(pve_node, esxi_name, datastore_name, vmname, headers):
    url = f"https://localhost:8006/api2/json/nodes/{pve_node}/storage/{esxi_name}/import-metadata"
    params = {
        "volume": f"ha-datacenter/{datastore_name}/{vmname}/{vmname}.vmx"
    }
    response = requests.get(url, params=params, headers=headers, verify=False)
    return response.json()

def get_next_vmid(headers):
    url = "https://localhost:8006/api2/json/cluster/nextid"
    response = requests.get(url, headers=headers, verify=False)
    return response.json()['data']

def process_import_data(import_data, tag, pve_storagename, vmid, config):
    data = import_data['data']
    name = data['create-args']['name']
    result = []

    net_replacement = config.get('network_replacement', {})
    disk_iothread = config.get('disk_iothread', '')
    disk_params = config.get('disk_params', '')

    result.append('cpu=Broadwell-noTSX')
    result.append(f'vmid={vmid}')

    for key, value in data['create-args'].items():
        if isinstance(value, (int, float)):
            value = str(value)
        if "media=cdrom" in value:
            value = "file=" + value
        if key=='scsihw':
            value = config.get('scsihw_replacement', value)
        value = urllib.parse.quote(value)
        result.append(f'{key}={value}')

    for key, value in data['net'].items():
        model = net_replacement.get(value['model'], value['model'])
        value_str = f"{model}={value['macaddr']},bridge=vmbr0,tag={tag}"
        encoded_value = urllib.parse.quote(value_str)
        result.append(f'{key}={encoded_value}')

    for key, value in data['disks'].items():
        volid_index = value['volid'].rindex(name)
        volid_suffix = value['volid'][volid_index:]
        disk_value = f"{pve_storagename}:{vmid}/{volid_suffix}"

        if disk_params:
            disk_value += f",{disk_params}"

        if key.startswith('scsi') and disk_iothread!='':
            disk_value += f',{disk_iothread}'

        encoded_disk_value = urllib.parse.quote(disk_value)
        result.append(f'{key}={encoded_disk_value}')

    result_str = '&'.join(result)
    return result_str

def create_directory(path):
    os.makedirs(path, exist_ok=True)

def process_vmdk_files(source_base_dir, target_directory, vmname):
    source_path = os.path.join(source_base_dir, vmname)
    relative_path = os.path.relpath(source_path,target_directory)
    print(relative_path)
    for root, _, files in os.walk(source_path):
        for file in files:
            if file.endswith(".vmdk") and not any(exclude in file for exclude in ["-flat", "-ctk"]):
                file_path = os.path.join(root, file)
                with open(file_path, 'r') as f:
                    content = f.read()

                # Replace for VMFS lines
                new_content = content.replace(f'VMFS "{vmname}', f'VMFS "{relative_path}/{vmname}')

                # Replace for changeTrackPath lines
                new_content = new_content.replace(f'changeTrackPath="{vmname}', f'changeTrackPath="{relative_path}/{vmname}')

                target_file_path = os.path.join(target_directory, file)
                with open(target_file_path, 'w') as f:
                    f.write(new_content)

def main():
    parser = argparse.ArgumentParser(description="Proxmox VM import script")
    parser.add_argument("--vmname", required=True, help="Name of the VM")
    parser.add_argument("--vlan_tag", required=True, help="VLAN Tag for network interfaces")
    parser.add_argument("--pve_node", required=True, help="Proxmox VE node name")
    parser.add_argument("--esxi_name", required=True, help="ESXi server name")
    parser.add_argument("--datastore_name", required=True, help="Datastore name")
    parser.add_argument("--pve_storagename", required=True, help="Proxmox storage name")
    parser.add_argument("--pve_storagepathprefix", required=True, help="Proxmox storage path prefix")
    parser.add_argument("--api_token_file", required=True, help="Path to curl header file containing API token")
    parser.add_argument("--config", help="Path to JSON config file for replacements and additions")
    args = parser.parse_args()

    headers = read_api_token(args.api_token_file)
    config = read_config_file(args.config)


    import_data = get_import_data(args.pve_node, args.esxi_name, args.datastore_name, args.vmname, headers)

    vmid = get_next_vmid(headers)
    print(f"VMID: {vmid}")

    vm_config = process_import_data(import_data, args.vlan_tag, args.pve_storagename, vmid, config)
    print(f"VM Config: {vm_config}")

    target_directory = f"{args.pve_storagepathprefix}/{args.pve_storagename}/images/{vmid}"
    create_directory(target_directory)

    source_base_dir = os.path.join("/mnt", args.esxi_name, args.datastore_name)
    process_vmdk_files(source_base_dir, target_directory, args.vmname)

    url = f"https://localhost:8006/api2/json/nodes/{args.pve_node}/qemu"
    headers['Content-Type'] = "application/x-www-form-urlencoded"
    response = requests.post(url, headers=headers, data=vm_config, verify=False)
    print(f"Response Status: {response.status_code}")
    print(f"Response Text: {response.text}")

if __name__ == "__main__":
    main()

replacements.json:
JSON:
{
  "network_replacement": {
    "e1000": "virtio"
  },
  "scsihw_replacement": "virtio-scsi-single",
  "disk_params": "aio=native,discard=on,ssd=1",
  "disk_iothread": "iothread=1"
}
 
Um die Disks der VMs dann "bulk" von VMDK ins Proxmox-eigene Format zu migrieren habe ich folgende Kommandozeile zusammengefrekelt:
Bash:
qm config 126 | grep local-directory | cut -d: -f1 | xargs -IREPLACE -n1 qm disk move 126 REPLACE target-storage --format qcow2

Die 126 ist natürlich die VM-ID, "local-directory" der Quell-Datastore. Bei "qm disk move" gibts noch ein paar weitere Parameter, z.B. das die Originaldisk nach dem umkopieren gelöscht werden soll etc. Sprich: die Zeile oben ist nur ein Hinweis, bitte verstehen und sinnvoll ergänzen!

Leider lässt sich das ganze nicht parallelisieren, weil Proxmox während des Verschiebens einer Disk ein Lock auf die VM hält...
 
Um die Disks der VMs dann "bulk" von VMDK ins Proxmox-eigene Format zu migrieren habe ich folgende Kommandozeile zusammengefrekelt:

Könntest du bitte so nett sein und oben reinschreiben, wie viele Maschinen du damit convertiert hast?

Wenn es 2 daheim im Bastelkeller waren - schreib das netterweise dazu. Es gibt halt Leute die mit 1000+ VMs von VMWare ggf. nächstes Jahr kommen. Wäre cool wenn die zwischen Bastelkeller und Corporate unterscheiden können.

^^^ sehr nett gemeint.
 
  • Like
Reactions: Johannes S
Hehe - ja, ist schon recht. Die Dinge, die ich hier gebaut habe, sind für meinen Job an einer Uni. Aktuell ists zwar etwas, was so nebenbei läuft, aber auch wir haben auf der Agenda innerhalb der nächsten 3 Jahre mit einigen hundert VMs von VMWare weg zu kommen.

Abgesehen davon, dass ich nicht weiß, ob wir wirklich bei Proxmox bleiben oder doch noch etwas anderes (XCP-ng) zum Einsatz kommt, suche ich nach Werkzeugen, die den Impact und die Arbeit einer Migration von VMs reduzieren. Allerdings bin ich mit der Entwicklung der oben genannten Dinger noch nicht über den Prototypen-Status hinaus - das meine ich aber schon kommuniziert zu haben, indem ich "fixmes" und so weiter angesprochen habe.

Aktuell ist es für meinen Geschmack noch zu fummelig, mit meinen Entwicklungen VMs von VMWare zu Proxmox zu übernehmen, soviel habe ich mit den <10 VMs, an denen ich das (ansonsten aber erfolgreich) getestet habe, schon gelernt. Das würde ich noch ändern, bevor ich in die "Massenproduktion" gehe - habe ich aber oben auch erwähnt. Die nötigen Daten per Python-Script aus dem VMWare-Api zu ziehen ist dank ChatGPT kein Voodoo - hab ich für was anderes schon fertig, müsste ich nur zusammenklöppeln.

Die Migrationsprozesse, die du hier im Thread beschrieben hast, sind sicher etwas größer - und wenn ich mich nicht irre, irgendwie wenigstens zum Teil offline gewesen - ich las etwas von abgeschalteten Klonen? Oder nutzt du die nur, um den Target-Datastore zu seeden und dann während der Downtime der Produktiv-VM nur noch den finalen Sync laufen zu lassen?

Andererseits ist der Datenkopier-Aspekt nur die eine Seite - wenn man hunderte liebevoll individualisierte VMs hat, brauchts so ein Script wie dieses hier, scheint mir - und der Prozess, die Platten mit Bordmitteln im laufenden Betrieb zu migrieren, funktioniert ganz brauchbar - auf jeden Fall besser als der Proxmox-Importer mit QEMU Block-Streaming... Ich frage mich, gerade wie gut Block-Streaming dann funktioniert, wenn man eine VM vom Proxmox-Backup-Server zurückholen will - aber das ist ein anderes Thema.

Am genialsten wäre natürlich, wenn Proxmox mit VMware-Snapshots klar kommen würde - weil man dann für inkrementelles Kopieren nicht auf Rsync-Magie angewiesen wäre und darauf, selbstgebaute Binaries auf (produktiven?) ESX-Servern zu starten...

Zu guter letzt müssen die VMDKs aber in ein Proxmox-Natives format umkonvertiert werden, und dann sind wir wieder bei der Kommandozeile, die ich oben geposted habe. Denn wenn man drei VMs mit je 26 Festplatten hat, macht das keinen Spaß, das manuell in der GUI zu klicken. Und wenn man es einmal für diesen Fall gebaut hat, kann man es auch bei VMs mit nur 3 Platten verwenden.
 
Hehe - ja, ist schon recht. Die Dinge, die ich hier gebaut habe, sind für meinen Job an einer Uni. Aktuell ists zwar etwas, was so nebenbei läuft, aber auch wir haben auf der Agenda innerhalb der nächsten 3 Jahre mit einigen hundert VMs von VMWare weg zu kommen.

Der Punkt für dich ist - ChatGPT Erbrochenes hast du als solches gekennzeichnet. Die zwei Generationen nach dir von der Uni werden den Luxus nicht mehr haben...
 
  • Like
Reactions: Johannes S
Joa - ich nutze das Sprachmodell vor allem, um nerviges Boilerplate-Kram in geschwätzigen Programmiersprachen abzukürzen. Wo die automatische Ergänzung per IDE nur Worte vorschlägt, gibts von ChatGPT halt gleich mehrere Sätze auf einmal. Nützliches Werkzeug - wenn man sich im klaren darüber ist, das es lediglich weitestgehend gut gewürfelt ist. Ich wehre mich gegen die Anthromorphisierung, die einem da so halb aufgezwungen wird und halb per Instinkt angeboren ist - nur weil es so tut als würde es mit mir reden, hat es noch lange nichts damit zu tun. Es ist und bleibt ein Computerprogramm, was sich, bei kritischer Prüfung der Ausgaben, als nützliches Werkzeug erweisen kann...

Aber irgendwie ist das jetzt auch Off-Topic.