VMware nach Broadcom verlassen: ein geprüfter Migrationsplan

VMware nach Broadcom verlassen: ein geprüfter Migrationsplan

Kurze Antwort (geprüft am 2026-11-03): Seit der Übernahme von VMware hat Broadcom den Verkauf von Dauerlizenzen eingestellt, die Produktliste in zwei Abo-Pakete zusammengefasst, das alte Cloud-Partnerprogramm in Europa beendet und in diesem Herbst den öffentlichen Download von VDDK entfernt - der Disk-Bibliothek, mit der die meisten Migrationstools VMware-Disks lesen. Heute berichtet The Register über einen quelloffenen, rein lesenden Ersatz für diese Bibliothek. Nicht jeder Ausweg braucht jedoch VDDK: Ein OVA-Export plus Disk-Konvertierung kommt ganz ohne VMware-Code aus. Im Folgenden: die Änderungen mit Datum, realistische Ziele für ein EU-Team, der Umzug Schritt für Schritt und ein Konverter, den wir an einem echten Export im VMware-Format getestet haben.

Quelle. "Architect creates open-source replacement for VM migration tool VMware has hidden" (Simon Sharwood, The Register, 2026-11-03). Weitere Fakten sind dort verlinkt, wo sie vorkommen. Ihr eigener Vertrag kann von den öffentlichen Bedingungen abweichen, klären Sie Lizenzdetails daher mit Ihrem Reseller.

Was Broadcom geändert hat, mit Datum

Datum	Änderung	Quelle
2023-12-11	Verkaufsende für Dauerlizenzen und Support-Verlängerungen; Angebot reduziert auf Abos von VMware Cloud Foundation (VCF) und vSphere Foundation (VVF)	Broadcom-Meldung, Krish Prasad
2025-03-28	Distributor Arrow teilt Partnern mit, dass die Mindestbestellung ab 2025-04-10 von 16 auf 72 Kerne pro Produktlinie steigt	The Register
2026-01-26	Verträge mit Cloud-Providern (VCSP) im EWR werden nicht verlängert; offene Deals bis 2026-03-31 abzuschließen; danach Programm nur auf Einladung	The Register, 2026-01-31
Aug-Sep 2026	VDDK aus dem öffentlichen Download entfernt: "The VDDK is not a customer entitlement" (VDDK ist kein Kundenanspruch), Zugang über ausgewählte TAP-Partner	TechTarget, 2026-09-09
2026-11-03	OpenVDDK von Andrija Panić: Apache-lizenzierter, rein lesender Drop-in-Ersatz für libvixDiskLib.so.8.0.3, der "contains no VMware code" (keinen VMware-Code enthält)	The Register, 2026-11-03

Zwei Einschränkungen. Das 72-Kern-Minimum meldete ein Distributor, nicht eine Broadcom-Seite, die wir finden konnten: Broadcoms Artikel zur Kernzählung (KB 313548, geprüft am 2026-11-03) sagt "You must license a minimum of 16 physical cores for each CPU" (mindestens 16 physische Kerne pro CPU), und einige Reseller berichten, das Bestellminimum von 72 Kernen sei wieder gefallen. Lassen Sie sich die Kernzahl im Angebot schriftlich bestätigen. Und auf EU-Ebene ist die Sache noch offen: Der Cloud-Branchenverband CISPE hat im Juli 2025 beim Gericht der EU beantragt, die Freigabe der Fusion durch die Kommission für nichtig zu erklären (Rechtssache T-503/25); ein Urteil haben wir bisher nicht gefunden.

Warum VDDK wichtig ist und welche Wege ohne auskommen

Die VDDK-Bibliothek libvixDiskLib erlaubt einem Tool, die Disks von VMs zu lesen, die noch in vSphere laufen. The Register nennt virt-v2v, nbdkit, die Importer von Forklift / MTV, Apache CloudStack und hauseigene Skripte unter den Tools, die sie laden. Microsofts VM Conversion Extension für Windows Admin Center (vCenter nach Hyper-V, mit Warm-Sync über Change Block Tracking) ist in ihrer Dokumentation (aktualisiert am 2026-02-20) weiterhin als Preview markiert, und Berichte zum Start führen VDDK unter den Voraussetzungen auf. OpenVDDK ist die neue Option für all diese Tools, mit der Warnung des Autors, dass Testerberichte "not independently audited customer endorsements" (keine unabhängig geprüften Kundenempfehlungen) sind.

Wege ganz ohne VDDK laut der virt-v2v-Dokumentation zum VMware-Input (geprüft am 2026-11-03): ein OVA-Export (-i ova), die VM-Dateien auf NFS oder über SSH (-i vmx, -it ssh), NFC und der einfache vCenter-HTTPS-Weg, den die Dokumentation "the slowest method" (die langsamste Methode) nennt. Der ESXi-Importassistent von Proxmox VE, angekündigt am 2024-03-27, liest Disks über die ESXi-API mit einem eigenen Rust-Dateisystem im User-Space und wurde gegen ESXi 6.5 bis 8.0 getestet (Proxmox-Forum).

Wohin umziehen: fünf realistische Ziele

Ziel	Passt, wenn	Worauf achten
Proxmox VE (KVM) auf eigener Hardware	3+ Hosts, ein Team, das GUI und Clustering will	Upgrades, Storage (ZFS, Ceph) und Support liegen bei Ihnen
OpenStack	Viele Mandanten, alles über eine API	Aufwendig im Betrieb; lohnt sich erst ab einer gewissen Größe
Hyper-V (Windows Server)	Windows-lastige Umgebung, Datacenter-Lizenzen bereits bezahlt	Microsofts Tool braucht zuerst Hyper-V-Treiber in Linux-Gästen
Cloud-Server (KVM)	Einige bis einige Dutzend VMs, kein Wunsch, einen Hypervisor zu betreiben	Ein Import pro VM, neue IP-Adressen
Dedizierte Server + eigener Hypervisor	Gleichmäßige Last, Sie wollen die ganze Maschine	Betrieb und Patches des Hypervisors übernehmen Sie selbst

Eine VM in fünf Schritten umziehen

1. Bestand aufnehmen und aufräumen. Notieren Sie Firmware (BIOS oder EFI), Disk-Controller, NIC-Typ, statische IPs und jede an eine MAC-Adresse gebundene Lizenz. Löschen oder konsolidieren Sie Snapshots, damit Sie eine einzige aktuelle Disk exportieren.
2. Den Gast vorbereiten, solange er noch auf VMware läuft. Windows: Installieren Sie jetzt die virtio-Treiber (virtio-win); ein Windows-Gast, der ohne sie auf eine virtio-Disk umzieht, bootet nicht. Linux: virtio-Treiber sind im Kernel, aber ein host-only initramfs kann sie auslassen; prüfen Sie das mit lsinitramfs oder lsinitrd und bauen Sie es bei Bedarf neu.
3. Exportieren oder verbinden. Fahren Sie die VM herunter und exportieren Sie ein OVF / OVA (vSphere Client "Export OVF Template" oder ovftool), oder lassen Sie virt-v2v oder den Proxmox-Assistenten die VM abholen.
4. Konvertieren. Nur die Disk mit qemu-img, den ganzen Gast mit virt-v2v (das auch Treiber anpasst) oder direkt aus dem OVF in Proxmox.
5. Über die Konsole booten, dann aufräumen. Prüfen Sie NIC-Namen und IP, entfernen Sie VMware Tools oder open-vm-tools, installieren Sie qemu-guest-agent.

qemu-img convert -p -f vmdk -O qcow2 disk1.vmdk disk1.qcow2
virt-v2v -i ova VM.ova -o local -os /var/tmp -of qcow2
qm importovf 120 VM.ovf local-lvm

Das sind die dokumentierten Aufrufe aus dem Handbuch des jeweiligen Tools; diese drei haben wir hier nicht ausgeführt. Die Konvertierung, die wir ausgeführt haben, folgt unten.

Getestet: was eine Konvertierung tatsächlich tut (ova2raw.js)

Um die beweglichen Teile zu zeigen, haben wir die Konvertierung in etwa 100 Zeilen Bun ohne Abhängigkeiten geschrieben. Das Skript öffnet ein OVA (ein einfaches tar), prüft das SHA-256-Manifest, gibt die Hardware aus, die das OVF anfordert, entpackt die streamOptimized-VMDK Grain für Grain in ein Sparse-Raw-Image und prüft die GPT. Wir haben es mit Ubuntus offiziellem 24.04-OVA gefüttert, einem echten Export im VMware-Format: noble-server-cloudimg-amd64.ova, Build vom 2026-10-17, dessen SHA-256 mit Ubuntus SHA256SUMS übereinstimmte. Speichern als ova2raw.js:

// ova2raw.js - check a VMware OVA export and turn its disk into a raw image for KVM
// usage: bun ova2raw.js <export.ova> <out.raw>
import { openSync, readSync, writeSync, ftruncateSync, closeSync, fstatSync } from 'node:fs'
import { inflateSync } from 'node:zlib'
import { createHash } from 'node:crypto'

const [ova, out] = process.argv.slice(2)
const fd = openSync(ova, 'r')
const read = (pos, len) => {
  const b = Buffer.alloc(len)
  readSync(fd, b, 0, len, pos)
  return b
}

// 1. an OVA is a plain tar: list its members
const files = {}
for (let o = 0; o + 512 <= fstatSync(fd).size; ) {
  const h = read(o, 512)
  if (h.every(x => x === 0)) break
  const name = h.toString('utf8', 0, 100).replace(/\0.*$/s, '')
  const size = parseInt(h.toString('ascii', 124, 136).replace(/\0.*$/s, '').trim(), 8)
  files[name] = { pos: o + 512, size }
  o += 512 + Math.ceil(size / 512) * 512
}
const find = ext => Object.keys(files).find(n => n.endsWith(ext))
const text = n => read(files[n].pos, files[n].size).toString('utf8')
console.log('OVA members:', Object.entries(files).map(([n, f]) => `${n} (${f.size} B)`).join(', '))

// 2. the .mf manifest: every member's SHA-256 must match
const mf = find('.mf')
for (const line of mf ? text(mf).split('\n') : []) {
  const m = line.match(/^SHA(1|256)\((.+)\)\s*=\s*([0-9a-f]+)/i)
  if (!m || !files[m[2]]) continue
  const h = createHash('sha' + m[1])
  const f = files[m[2]]
  for (let p = 0; p < f.size; p += 1 << 24) h.update(read(f.pos + p, Math.min(1 << 24, f.size - p)))
  console.log(`  manifest ${m[2]}: ${h.digest('hex') === m[3].toLowerCase() ? 'OK' : 'MISMATCH'}`)
}

// 3. the .ovf descriptor: what the VM expects from its hardware
const ovf = text(find('.ovf'))
const items = [...ovf.matchAll(/<(?:ovf:)?Item\b[\s\S]*?<\/(?:ovf:)?Item>/g)].map(x => x[0])
const tag = (s, t) => s.match(new RegExp(`<(?:rasd:)?${t}>([^<]*)<`))?.[1]
const kind = { 3: 'CPU', 4: 'RAM', 5: 'IDE controller', 6: 'SCSI controller', 10: 'NIC', 17: 'disk', 20: 'SATA controller' }
console.log('OVF:', ovf.match(/vmw:osType="([^"]+)"/)?.[1] ?? '?', '| firmware',
  ovf.match(/key="firmware" ovf:value="([^"]+)"/)?.[1] ?? 'bios (default)')
for (const it of items) {
  const k = kind[tag(it, 'ResourceType')]
  if (k) console.log(`  ${k.padEnd(16)} ${tag(it, 'ElementName') ?? ''} ${tag(it, 'ResourceSubType') ?? ''} ${tag(it, 'VirtualQuantity') ?? ''}`.trimEnd())
}

// 4. the streamOptimized VMDK: a header, then compressed grains and markers
const vmdk = files[find('.vmdk')]
const hd = read(vmdk.pos, 512)
if (hd.readUInt32LE(0) !== 0x564d444b) throw new Error('not a sparse VMDK (no KDMV magic)')
const capacity = Number(hd.readBigUInt64LE(12)) * 512
const desc = read(vmdk.pos + Number(hd.readBigUInt64LE(28)) * 512, Number(hd.readBigUInt64LE(36)) * 512)
console.log(`VMDK ${desc.toString().match(/createType="([^"]+)"/)?.[1]}, virtual size ${capacity} B, grain ${Number(hd.readBigUInt64LE(20)) * 512} B`)

const ofd = openSync(out, 'w')
ftruncateSync(ofd, capacity) // sparse: unwritten grains stay holes = zeros
let pos = Number(hd.readBigUInt64LE(64)) * 512
let grains = 0
let written = 0
while (pos < vmdk.size) {
  const m = read(vmdk.pos + pos, 512)
  const val = Number(m.readBigUInt64LE(0))
  const size = m.readUInt32LE(8)
  if (size) { // compressed grain: lba, size, zlib data
    const raw = inflateSync(read(vmdk.pos + pos + 12, size))
    writeSync(ofd, raw, 0, raw.length, val * 512)
    grains++
    written += raw.length
    pos += Math.ceil((12 + size) / 512) * 512
  } else if (m.readUInt32LE(12) === 0) break // end-of-stream marker
  else pos += 512 + val * 512 // grain table / directory / footer: metadata only
}
closeSync(ofd)
console.log(`Wrote ${out}: ${grains} grains, ${written} B of data in ${capacity} B`)

// 5. check the result: a valid GPT, and the file systems where the partitions say they are
const rfd = openSync(out, 'r')
const at = (p, l) => { const b = Buffer.alloc(l); readSync(rfd, b, 0, l, p); return b }
const gpt = at(512, 92)
const crc = Buffer.from(gpt)
crc.writeUInt32LE(0, 16)
console.log(`GPT "${gpt.toString('ascii', 0, 8)}", header CRC ${(Bun.hash.crc32(crc) >>> 0) === gpt.readUInt32LE(16) ? 'OK' : 'BAD'}`)
const n = gpt.readUInt32LE(80)
const es = gpt.readUInt32LE(84)
const ents = at(Number(gpt.readBigUInt64LE(72)) * 512, n * es)
console.log(`  partition array CRC ${(Bun.hash.crc32(ents) >>> 0) === gpt.readUInt32LE(88) ? 'OK' : 'BAD'}`)
for (let i = 0; i < n; i++) {
  const e = ents.subarray(i * es, (i + 1) * es)
  if (e.subarray(0, 16).every(x => x === 0)) continue
  const first = Number(e.readBigUInt64LE(32))
  const last = Number(e.readBigUInt64LE(40))
  const sb = at(first * 512 + 1024, 136)
  const fs = sb.readUInt16LE(56) === 0xef53 ? `ext4 label "${sb.toString('ascii', 120, 136).replace(/\0.*$/s, '')}"`
    : at(first * 512, 512).toString('ascii', 82, 87) === 'FAT32' ? 'FAT32 (EFI system partition)'
    : e.toString('ascii', 0, 16) === 'Hah!IdontNeedEFI' ? 'BIOS boot (GRUB for legacy BIOS)' : 'unknown'
  console.log(`  p${i + 1} ${String((last - first + 1) * 512 / 2 ** 20 | 0).padStart(5)} MiB  ${fs}`)
}

bun ova2raw.js noble-server-cloudimg-amd64.ova noble.raw

Ausgabe, ausgeführt auf einem DCXV Cloud-Server mit Bun 1.4.4 am 2026-11-03:

OVA members: ubuntu-noble-24.04-cloudimg.ovf (11186 B), ubuntu-noble-24.04-cloudimg.mf (213 B), ubuntu-noble-24.04-cloudimg.vmdk (590749696 B)
  manifest ubuntu-noble-24.04-cloudimg.vmdk: OK
  manifest ubuntu-noble-24.04-cloudimg.ovf: OK
OVF: ubuntu64Guest | firmware bios (default)
  CPU              2 virtual CPU(s)  2
  RAM              1024MB of memory  1024
  SCSI controller  SCSI Controller 0 VirtualSCSI
  IDE controller   VirtualIDEController 1
  IDE controller   VirtualIDEController 0
  disk             Hard Disk 1
  NIC              Ethernet 1 VmxNet3
VMDK streamOptimized, virtual size 10737418240 B, grain 65536 B
Wrote noble.raw: 28663 grains, 1878458368 B of data in 10737418240 B
GPT "EFI PART", header CRC OK
  partition array CRC OK
  p1  2558 MiB  ext4 label "cloudimg-rootfs"
  p14     4 MiB  BIOS boot (GRUB for legacy BIOS)
  p15   106 MiB  FAT32 (EFI system partition)
  p16   913 MiB  ext4 label "BOOT"

Drei Läufe dauerten auf diesem Server 14.6 bis 16.2 s Echtzeit. Die Raw-Datei ist 10 GiB groß und belegt 1.8 GB auf der Disk.

Was die Ausgabe Ihnen vor der Umstellung sagt

1. VmxNet3 und VirtualSCSI sind VMware-Geräte. Unter KVM werden daraus virtio-net und virtio-blk oder virtio-scsi. Der Gast braucht vor dem ersten Boot Treiber für beide, und die Netzwerkschnittstelle bekommt meist einen neuen Namen, sodass eine an den alten Namen gebundene statische IP nicht hochkommt. Nutzen Sie für den ersten Boot die Konsole.
2. Die Firmware muss passen. Dieses OVF setzt nichts, also ist es BIOS; die Disk enthält sowohl eine BIOS-Boot- als auch eine EFI-Systempartition und bootet daher auf beide Arten. Eine mit firmware=efi exportierte VM braucht auf dem Ziel UEFI (OVMF), sonst findet sie keinen Bootloader.
3. Thin bleibt nur thin, wenn Sie darauf achten. 10 GiB virtuell, 1.8 GB Daten. Kopieren Sie mit Sparse-fähigen Tools (cp --sparse=always, rsync -S) oder nutzen Sie qcow2, sonst übertragen und speichern Sie Nullen.
4. Das Manifest ist Ihre Transferprüfung. Prüfen Sie den SHA-256 nach jeder Kopie zwischen Standorten: Ein abgebrochener Upload lässt sich klaglos in eine Disk konvertieren, die später versagt.

Die Ausfallzeit planen

Ein Cold-Umzug kostet Export + Transfer + Konvertierung + ersten Boot. Messen Sie jeden Schritt an einer Test-VM und multiplizieren Sie dann. Transfer-Rechnung (unsere, ohne Protokoll-Overhead): 1.8 GB bei 1 Gbit/s sind etwa 15 s, 1 TB etwa 2.2 Stunden. Warm-Tools kopieren, während die VM läuft, und senden am Ende nur geänderte Blöcke; die Tester von The Register berichten von Cold- und Warm-Läufen mit Forklift und MTV. Für Datenbanken und stark genutzte Anwendungen schlägt Replikation plus DNS-Umschaltung jede Disk-Kopie: Senken Sie zuerst die TTL (siehe DNS-Propagation und TTL) und folgen Sie den Checklisten in Migration auf einen Cloud-Server.

Wann DCXV Cloud- oder dedizierte Server passen

• Eine Handvoll VMs, kein Hypervisor-Team: Unsere Cloud-Server laufen auf KVM mit virtio-Disks. Im Panel nimmt Neuinstallation -> "Eigenes Image (URL)" eine qcow2-, raw- oder vmdk-Datei über https an; ein Image, das größer als die Disk des Tarifs ist, vergrößert die Disk und wird als Disk-Upgrade berechnet, und Netzwerkeinstellungen werden nur angewendet, wenn das Image cloud-init enthält. Tarife ab EUR 15.00/Monat (2 vCPU, 4 GB RAM, 40 GB; geprüft am 2026-11-03, ohne MwSt.).
• Dutzende VMs oder ein eigener Proxmox-Cluster: dedizierte Server ab EUR 210/Monat, mit dem Hypervisor Ihrer Wahl.
• Windows-Gäste: Wir verkaufen Windows-Server-Lizenzen weiter; fragen Sie vor dem Umzug, damit die Lizenz ab dem ersten Tag bereitsteht.

Beide laufen in unseren Rechenzentren nach Tier III in Prag und Covilha.

Den Umzug mit uns planen

Führen Sie ova2raw.js auf einer exportierten VM aus und senden Sie die Hardware-Zeilen der Ausgabe an sales@dcxv.com, oder starten Sie einen Cloud-Server und testen Sie den Import selbst.