Converting VMware disks to qcow2 and raw for STACKIT

Input and output: one boot disk, one data disk

A demo estate written for this page and assessed by StackToIT on 4 November 2026: six VMs, two port groups. Left: the first six rows of the vDisk sheet. Right: the data volume the run drafts for the second disk of erp-app01; the review comments above the blocks are left out.

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-0003

resource "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
}

• The boot disk is not a volume block

  Hard disk 1 of erp-app01 (81920 MiB) becomes the boot volume of the server, 80 GiB, started from an image. The image itself is a variable, because the draft cannot know which image you will upload.

• The data disk becomes a volume

  Hard disk 2 (409600 MiB) becomes a 400 GiB volume with an attachment to the server. The comment in the file says to copy the data after the volume exists: the disk content never travels through Terraform.

• Thin or thick is read, not carried

  The Thin column says hard disk 2 is thick and hard disk 1 is thin. Both are drafted at their full capacity, so a thin 400 GiB disk with 100 GiB of data still becomes a 400 GiB volume unless you decide otherwise.

What no conversion can carry

The same run. Left: rows 4 to 11 of the vDisk sheet, with the raw device mapping of erp-db01 (Raw is True) and the multi-writer disks of the two SQL nodes. Right: the table of units the run leaves for the architect, from 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

  The LUN behind a raw mapping is not part of the VM, so exporting and converting the VM does not copy it. The run classifies erp-db01 as MANUAL_REVIEW and drafts no server for it.

• Shared and multi-writer disks

  Both SQL nodes reference the same 200 GiB disk. The run stops at MANUAL_REVIEW for both. STACKIT documents that a data volume attaches to one server at a time, so the cluster design is the question, not the disk format.

• The template

  tpl-win2019 is a template. It becomes a STACKIT image and has no Terraform block; the run lists it for you to convert or to rebuild from a public image.

Disk by disk: what the run does and what you do

Run figures: 8 units, 4 drafted and 4 left for the architect; 24 steps in the plan, 10 of them automated, and the run reports that none of the automated ones can run as written yet, because the variables for image IDs, machine types, network prefixes and nameservers are still open.

From VMDK to a STACKIT image

The first two steps follow the run. The conversion commands are common practice, not something StackToIT runs or checks.

1. 01

   Consolidate snapshots

   The run reports files01 with a snapshot. Delete or consolidate snapshots first, because only the current state of a disk is exported.

2. 02

   Get the VMDK out of the datastore

   Copy the disk file out of the datastore or export the VM, for example with the vSphere client or ovftool. Power the VM off for the final copy.

3. 03

   Convert

   For example: qemu-img convert -f vmdk -O qcow2 erp-app01.vmdk erp-app01.qcow2, or -O raw for a raw file. STACKIT shows the same tool with -O raw for formats it does not accept. Check the result with qemu-img info.

4. 04

   Create the image and upload

   The IaaS API how-to has you create the image first (a POST with diskFormat raw, qcow2 or iso, which returns an image ID and an upload URL), then upload the file to that URL with an HTTP PUT within a few hours, and wait for the state AVAILABLE.

5. 05

   Set the variable

   Put the image ID into vm_erp_app01_image_id. The draft declares the variable but writes no image resource, so the image exists before the first plan.

6. 06

   Create volumes, copy the data, boot

   Apply the draft, copy each data disk to its volume, then start the server and test it before you touch DNS.

The image variable the draft expects

From the same run, variables.tf. The variable has no default, so the plan will not proceed without the image you built.

variable "vm_erp_app01_image_id" {
  type        = string
  description = "STACKIT image converted from the boot disk of VM erp-app01 (qcow2 or raw)."
}

What to decide before you apply

• Boot disks above the image limit

  erp-app01 has an 80 GiB boot disk and the STACKIT page states a 70 GB maximum image size. The page does not say whether that counts the file or the virtual size, so ask STACKIT, then choose: shrink the system partition before export, or install from a public image and move the application.

• qcow2 or raw

  Both are accepted. qcow2 files are usually smaller to upload because unused space is not stored; raw is the simplest to reason about. Pick one per estate and keep it.

• Windows licences

  STACKIT provides Windows Server images for 2016, 2019, 2022 and 2025, and for its standard images the licence is included. For an image you upload, STACKIT provides no Windows Server licence: you license it yourself through the Flexible Virtualization Benefit, which needs subscription licences or Software Assurance. tpl-win2019 is such a case if you convert it rather than rebuild it.

• Volume sizes

  Drafted sizes equal source capacity. Because a volume cannot shrink, right-size thin disks before creating the volume.

• The raw mapping and the shared disk

  Both are design decisions. Record them in the decision register the run writes rather than leaving them as comments.

Questions about disk conversion

Sources

• STACKIT docs: How to use custom Images with the IaaS-API
• STACKIT docs: Concepts of Block Storage
• STACKIT docs: Windows Server licensing guide
• STACKIT docs: Creating a new Windows Server with the API