VMWARE → STACKIT · TUTORIAL
VMware-Festplatten für STACKIT nach qcow2 und raw konvertieren
STACKIT nimmt Festplatten-Images als qcow2 oder raw an (die Image-API nennt zusätzlich iso), nicht als VMDK. Diese Anleitung bewertet einen kleinen RVTools-Export mit acht Einheiten und zeigt, welche Festplatten der Entwurf zu Boot-Image, Datenvolume oder gar nichts macht und welche Platten keine Konvertierung übertragen kann: ein Raw Device Mapping und eine geteilte Cluster-Platte.
Eingabe und Ausgabe: eine Boot-Platte, eine Datenplatte
Eine für diese Seite geschriebene Demo-Umgebung, am 4. November 2026 von StackToIT bewertet: sechs VMs, zwei Portgruppen. Links die ersten sechs Zeilen des Blatts vDisk. Rechts das Datenvolume, das der Lauf für die zweite Platte von erp-app01 entwirft; die Review-Kommentare über den Blöcken sind weggelassen.
VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
erp-app01,Hard disk 1,81920,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-ssd01] erp-app01/erp-app01.vmdk,4203-c001-0001
erp-app01,Hard disk 2,409600,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[vmfs-ssd01] erp-app01/erp-app01_1.vmdk,4203-c001-0001
erp-db01,Hard disk 1,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-ssd01] erp-db01/erp-db01.vmdk,4203-c001-0002
erp-db01,Hard disk 2,1048576,True,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd01] erp-db01/erp-db01_1.vmdk,4203-c001-0002
files01,Hard disk 1,51200,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-nl02] files01/files01.vmdk,4203-c001-0003
files01,Hard disk 2,2048000,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl02] files01/files01_1.vmdk,4203-c001-0003resource "stackit_volume" "vm_erp_app01_disk2" {
project_id = var.project_id
name = "erp-app01-disk2"
availability_zone = var.availability_zone
size = 400
performance_class = var.vmware_volume_performance_class
}
resource "stackit_server_volume_attach" "vm_erp_app01_disk2" {
project_id = var.project_id
server_id = stackit_server.vm_erp_app01.server_id
volume_id = stackit_volume.vm_erp_app01_disk2.volume_id
}Die Boot-Platte ist kein Volume-Block
Hard disk 1 von erp-app01 (81920 MiB) wird zum Boot-Volume des Servers mit 80 GiB und startet aus einem Image. Das Image selbst ist eine Variable, weil der Entwurf nicht wissen kann, welches Image Sie hochladen.
Die Datenplatte wird ein Volume
Hard disk 2 (409600 MiB) wird ein Volume mit 400 GiB samt Anbindung an den Server. Der Kommentar in der Datei sagt, die Daten nach dem Anlegen des Volumes zu kopieren: Der Inhalt der Platte läuft nie durch Terraform.
Thin oder Thick wird gelesen, nicht übernommen
Die Spalte Thin nennt Platte 2 als Thick und Platte 1 als Thin. Beide werden mit voller Kapazität entworfen. Eine Thin-Platte mit 400 GiB und 100 GiB Daten wird also ein Volume mit 400 GiB, solange Sie nichts anderes entscheiden.
Was keine Konvertierung übertragen kann
Derselbe Lauf. Links die Zeilen 4 bis 11 des Blatts vDisk mit dem Raw Device Mapping von erp-db01 (Raw ist True) und den Multi-Writer-Platten der beiden SQL-Knoten. Rechts die Tabelle der Einheiten, die der Lauf Ihnen überlässt, aus terraform/README.md.
erp-db01,Hard disk 1,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-ssd01] erp-db01/erp-db01.vmdk,4203-c001-0002
erp-db01,Hard disk 2,1048576,True,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd01] erp-db01/erp-db01_1.vmdk,4203-c001-0002
files01,Hard disk 1,51200,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-nl02] files01/files01.vmdk,4203-c001-0003
files01,Hard disk 2,2048000,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl02] files01/files01_1.vmdk,4203-c001-0003
sql-node01,Hard disk 1,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-ssd01] sql-node01/sql-node01.vmdk,4203-c001-0004
sql-node01,Hard disk 2,204800,False,persistent,sharingMultiWriter,False,SCSI controller 2,virtualSharing,[vmfs-ssd01] sql-node01/sql-node01_1.vmdk,4203-c001-0004
sql-node02,Hard disk 1,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-ssd01] sql-node02/sql-node02.vmdk,4203-c001-0005
sql-node02,Hard disk 2,204800,False,persistent,sharingMultiWriter,False,SCSI controller 2,virtualSharing,[vmfs-ssd01] sql-node01/sql-node01_1.vmdk,4203-c001-0005| Source | Class | Why |
|---|---|---|
| `vm.erp-db01` | MANUAL_REVIEW / MEDIUM | Raw device mapping: the LUN is not part of the VM image, so an image export does not carry its data; it needs a block- or application-level copy to a STACKIT volume. |
| `vm.sql-node01` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.sql-node02` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.tpl-win2019` | REPLATFORM / MEDIUM | VM template: convert the VMDK to qcow2/raw and upload it with stackit_image, or rebuild it from a STACKIT public image. |Raw Device Mapping
Die LUN hinter einem Raw-Mapping gehört nicht zur VM; Export und Konvertierung der VM kopieren sie also nicht. Der Lauf stuft erp-db01 als MANUAL_REVIEW ein und entwirft keinen Server.
Geteilte und Multi-Writer-Platten
Beide SQL-Knoten verweisen auf dieselbe Platte mit 200 GiB. Der Lauf hält bei beiden bei MANUAL_REVIEW an. STACKIT dokumentiert, dass ein Datenvolume immer nur an einem Server hängt; offen ist also das Cluster-Design, nicht das Plattenformat.
Das Template
tpl-win2019 ist ein Template. Es wird ein STACKIT-Image und hat keinen Terraform-Block; der Lauf führt es als offene Einheit, die Sie konvertieren oder aus einem öffentlichen Image neu aufbauen.
Platte für Platte: Was der Lauf tut und was Sie tun
| Platte im Export | Was der Lauf schreibt | Was Sie tun |
|---|---|---|
| erp-app01, Hard disk 1: 80 GiB, thin, Boot | Boot-Volume des Servers, 80 GiB, Image-ID als Variable | Konvertieren, hochladen, Variable setzen. Die STACKIT-Seite nennt 70 GB als Höchstgröße eines Images; entscheiden Sie, wie eine Platte mit 80 GiB dorthin kommt. |
| erp-app01, Hard disk 2: 400 GiB, thick | stackit_volume mit 400 GiB und Anbindung | Daten nach dem Anlegen des Volumes kopieren. |
| files01, Hard disk 2: 2000 GiB, thin | stackit_volume mit 2000 GiB und Anbindung | Innerhalb der Spanne von 1 GB bis 16 TB je Datenvolume; ein Volume wächst nur im abgehängten Zustand und schrumpft nie. |
| erp-db01, Hard disk 2: 1 TiB Raw Mapping | Nichts: MANUAL_REVIEW, kritischer Befund | Kopie auf Blockebene oder Anwendungsebene auf ein STACKIT-Volume. |
| sql-node01 und sql-node02, Hard disk 2: geteilt, Multi-Writer | Nichts: MANUAL_REVIEW bei beiden Knoten | Cluster-Speicher oder Cluster selbst neu entwerfen. |
| tpl-win2019: Template | Kein Block; bei den offenen Einheiten aufgeführt | VMDK in ein Image konvertieren oder aus einem öffentlichen Windows-Image neu bauen. |
| files01: ein Snapshot | Informativer Befund | Vor dem Export konsolidieren; migriert wird nur der aktuelle Stand. |
Kennzahlen des Laufs: 8 Einheiten, 4 entworfen und 4 für den Architekten offen; 24 Schritte im Plan, davon 10 automatisiert; laut Lauf ist noch keiner der automatisierten Schritte so ausführbar, wie er dasteht, weil die Variablen für Image-IDs, Maschinentypen, Netzwerkpräfixe und Nameserver offen sind.
Von der VMDK zum STACKIT-Image
Die ersten beiden Schritte folgen dem Lauf. Die Konvertierungsbefehle sind übliche Praxis; StackToIT führt sie weder aus noch prüft es sie.
Snapshots konsolidieren
Der Lauf meldet bei files01 einen Snapshot. Löschen oder konsolidieren Sie Snapshots zuerst, denn exportiert wird nur der aktuelle Stand einer Platte.
VMDK aus dem Datastore holen
Kopieren Sie die Plattendatei aus dem Datastore oder exportieren Sie die VM, zum Beispiel mit dem vSphere Client oder ovftool. Für die letzte Kopie schalten Sie die VM aus.
Konvertieren
Zum Beispiel: qemu-img convert -f vmdk -O qcow2 erp-app01.vmdk erp-app01.qcow2, oder -O raw für eine Raw-Datei. STACKIT zeigt dasselbe Werkzeug mit -O raw für nicht akzeptierte Formate. Das Ergebnis prüfen Sie mit qemu-img info.
Image anlegen und hochladen
Laut IaaS-API-Anleitung legen Sie zuerst das Image an (POST mit diskFormat raw, qcow2 oder iso; die Antwort enthält Image-ID und Upload-URL), laden die Datei innerhalb weniger Stunden per HTTP PUT dorthin hoch und warten auf den Status AVAILABLE.
Variable setzen
Tragen Sie die Image-ID in vm_erp_app01_image_id ein. Der Entwurf deklariert die Variable, schreibt aber keine Image-Ressource; das Image muss vor dem ersten Plan existieren.
Volumes anlegen, Daten kopieren, booten
Wenden Sie den Entwurf an, kopieren Sie jede Datenplatte auf ihr Volume, starten Sie den Server und testen Sie ihn, bevor Sie DNS anfassen.
Die Image-Variable, die der Entwurf erwartet
Aus demselben Lauf, variables.tf. Die Variable hat keinen Standardwert; ohne Ihr Image läuft der Plan nicht durch.
variable "vm_erp_app01_image_id" {
type = string
description = "STACKIT image converted from the boot disk of VM erp-app01 (qcow2 or raw)."
}Was Sie vor dem Anwenden entscheiden
Boot-Platten über dem Image-Limit
erp-app01 hat eine Boot-Platte mit 80 GiB, und die STACKIT-Seite nennt 70 GB als maximale Image-Größe. Ob damit die Dateigröße oder die virtuelle Größe gemeint ist, steht dort nicht; fragen Sie bei STACKIT nach und wählen Sie dann: Systempartition vor dem Export verkleinern oder aus einem öffentlichen Image installieren und die Anwendung umziehen.
qcow2 oder raw
Beides wird akzeptiert. qcow2-Dateien sind meist kleiner im Upload, weil ungenutzter Platz nicht gespeichert wird; raw ist am einfachsten zu überblicken. Wählen Sie eines je Umgebung und bleiben Sie dabei.
Windows-Lizenzen
STACKIT stellt Windows-Server-Images für 2016, 2019, 2022 und 2025 bereit; bei diesen Standard-Images ist die Lizenz enthalten. Für ein hochgeladenes Image liefert STACKIT keine Windows-Server-Lizenz: Sie lizenzieren es selbst über den Flexible Virtualization Benefit, der Subscription-Lizenzen oder Software Assurance voraussetzt. Genau das betrifft tpl-win2019, wenn Sie das Template konvertieren statt neu aufzubauen.
Volume-Größen
Die entworfenen Größen entsprechen der Quellkapazität. Weil ein Volume nicht schrumpft, dimensionieren Sie Thin-Platten vor dem Anlegen passend.
Raw Mapping und geteilte Platte
Beides sind Architekturentscheidungen. Halten Sie sie im Entscheidungsregister des Laufs fest, statt sie als Kommentar im Code stehen zu lassen.
Fragen zur Plattenkonvertierung
Konvertiert StackToIT meine VMDK-Dateien?
Nein. Es liest den RVTools-Export und schreibt einen Plan und einen Terraform-Entwurf. Plattendateien liest es nicht, Daten überträgt es nicht; die Konvertierung ist Ihr Schritt.
Welche Plattenformate akzeptiert STACKIT?
Die IaaS-API-Anleitung nennt raw, qcow2 und iso als Werte für diskFormat. VMDK gehört nicht dazu; konvertieren Sie also zuerst.
Warum wird das Raw Device Mapping nicht einfach mitkopiert?
Die gemappte LUN liegt außerhalb des VM-Images. Ein Export enthält die Mapping-Datei, nicht die Daten dahinter; diese brauchen eine Kopie auf Block- oder Anwendungsebene auf ein STACKIT-Volume.
Kann ich ein Volume an zwei Server hängen?
Laut der STACKIT-Seite zu den Block-Storage-Konzepten nicht: Multi-Attach wird nicht unterstützt; ein Datenvolume gehört immer nur zu einem Server.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.