VMWARE → STACKIT · SIZING TUTORIAL
Sizing VMware VMs for STACKIT: CPU, memory and disk
StackToIT reads CPU count, memory and disk capacity from the RVTools export and states the source size on every server it drafts. It does not pick the machine type, and it sizes disks from what was provisioned, not from what is used. This tutorial runs a six-VM demo estate with awkward sizes through StackToIT and shows the rounding it applies and the three cases it hands back to you: a memory reservation, a snapshot and a raw device mapping.
Disks: provisioned capacity in, whole GiB out
A demo export assessed by StackToIT on 4 November 2026. Left: the three vDisk rows of sz-big01, a file server with thin disks. Right: the two data volumes the draft writes for it, comment lines left out.
VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,VM UUID
sz-big01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4208-dddd-0004
sz-big01,Hard disk 2,1048576,False,persistent,sharingNone,True,SCSI controller 1,noSharing,4208-dddd-0004
sz-big01,Hard disk 3,2086528,False,persistent,sharingNone,True,SCSI controller 1,noSharing,4208-dddd-0004resource "stackit_volume" "vm_sz_big01_disk2" {
project_id = var.project_id
name = "sz-big01-disk2"
availability_zone = var.availability_zone
size = 1024
performance_class = var.vmware_volume_performance_class
}
resource "stackit_volume" "vm_sz_big01_disk3" {
project_id = var.project_id
name = "sz-big01-disk3"
availability_zone = var.availability_zone
size = 2038
performance_class = var.vmware_volume_performance_class
}Exact GiB stay exact
1048576 MiB is 1024 GiB and becomes size 1024. The boot disk of 61440 MiB becomes a 60 GiB boot volume.
Everything else is rounded up
2086528 MiB is 2037.6 GiB and becomes 2038. The same happens to sz-odd01, whose 51201 MiB boot disk becomes 51 GiB, one MiB over 50 GiB. Rounding up never shrinks a disk.
Thin disks are drafted at full size
sz-big01 has 3195904 MiB provisioned and 1450000 MiB in use. The draft follows the provisioned capacity; the in-use figure appears among the properties the run lists as unaccounted and is not used for sizing, so right-sizing is a decision you take.
The rounding in this run
| VM and disk | Source (vDisk) | Draft |
|---|---|---|
| sz-small01, Hard disk 1 | 20480 MiB | boot volume 20 GiB |
| sz-odd01, Hard disk 1 | 51201 MiB | boot volume 51 GiB |
| sz-mem01, Hard disk 1 and 2 | 102400 MiB and 512000 MiB | boot volume 100 GiB, volume 500 GiB |
| sz-big01, Hard disks 1 to 3 | 61440, 1048576 and 2086528 MiB | boot volume 60 GiB, volumes 1024 and 2038 GiB |
| sz-snap01, Hard disk 1 | 61440 MiB | boot volume 60 GiB |
Five servers and three volumes in all, read from terraform/compute.tf. The sixth VM, sz-rdm01, gets no block at all: see below.
Pick the machine family from the ratio
Every drafted server carries a machine type variable whose description states the source size, for example source 6 vCPU / 12 GiB for sz-odd01. STACKIT names families by CPU-to-RAM ratio, so the ratio of the source is a good first filter.
1:2, processor-optimized (family c)
sz-small01 (1 vCPU, 2 GiB), sz-odd01 (6 vCPU, 12 GiB) and sz-snap01 (2 vCPU, 4 GiB). For tiny machines the page also lists a t family of smaller instances.
1:4, general purpose (family g)
sz-big01 (16 vCPU, 64 GiB) and, by its source size, sz-rdm01 (4 vCPU, 16 GiB).
1:16 or higher, large memory-optimized (family b)
sz-mem01 (8 vCPU, 128 GiB) is 1:16, the ratio the page gives for the b family. The m family is 1:8: an m type with 128 GiB would bring 16 vCPU, twice what the source uses.
Then read the exact catalogue
The machine types page states that vCPU, RAM or storage cannot be customized beyond the listed variants. Odd counts such as 6 vCPU need a check against the generation you want; a d in the type name marks a CPU without overcommit, and the page marks Windows Server compatibility per type.
A memory reservation cannot be expressed
sz-mem01 reserves all of its 128 GiB. Left: the vMemory sheet. Right: the two lines of the run that state what the draft does about it.
VM,Size MiB,Reservation,VM UUID
sz-mem01,131072,131072,4208-dddd-0003
sz-odd01,12288,0,4208-dddd-0002 - Why: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. A memory reservation is a capacity floor that stackit_server cannot express (machine_type is a fixed catalogue size); a person checks the chosen machine type against it. The value is as exported, unit unstated.
- Done when: A person checks the chosen machine type against the memory reservation of the source VM and sets a machine type that holds it, since stackit_server cannot express a reservation and machine_type is a fixed catalogue size.What you do
Check the chosen machine type against the reservation of the source. The sheet gives the figure without a unit, and the run keeps it as exported.
Also flagged at zero
sz-odd01 exports a reservation of 0 and still carries the setting as open, so in this run the item appears on every VM that has a vMemory row.
Three VMs that need more than a size
sz-snap01: snapshot
The export lists a 21504 MiB snapshot. The run says snapshots are restore points that are not migrated; only the current state is exported. Delete or consolidate it before you export the disk.
sz-rdm01: raw device mapping
One disk has Raw=True. The class is manual review, no Terraform is written, and the step says an image export does not carry the LUN: it needs a block or application level copy to a STACKIT volume.
sz-mem01: reservation
Handled above: the reservation is a capacity floor that a fixed catalogue size cannot state.
Disk mode
Every VM carries a disk-mode setting for review, including the independent persistent disk of sz-rdm01. In VMware, independent disks are left out of snapshots, so record what each one is.
Before you apply: sizing rules on the target side
Boot volumes are final
STACKIT states that the OS disk cannot be modified afterwards, and a boot volume cannot be detached. Size the boot_volume in the draft deliberately.
Data volumes grow, never shrink
A data volume is 1 GB to 16 TB. It can be enlarged while it is not attached to any instance; reducing capacity is not possible. A volume sized from the in-use figure can be grown later (detached, so plan a short window); one sized too large stays that size.
Choose one performance class
The draft keeps one variable, vmware_volume_performance_class, for all migrated data disks. The classes run from perf0 with at most 120 IOPS and 25 MB/s up to perf29 with at most 60000 IOPS and 1500 MB/s; STACKIT states that the class is independent of the volume size.
Write the decision down
Answer the machine type and class variables in review/target-values.tfvars and run the assessment again on the same folder. The next run reads your answers.
Sizing questions
Does StackToIT choose the STACKIT machine type?
No. The draft declares a machine type variable per server and states the source vCPU and memory in its description. You choose from the STACKIT catalogue.
Are disks sized from used space?
No. They follow the provisioned capacity from vDisk, rounded up to whole GiB. The in-use figure from vInfo is listed as unaccounted and sizes nothing.
Why is a VM with a raw device mapping not drafted?
The LUN is not part of the VM image, so an image export would not carry its data. The run classifies the VM as manual review and leaves the design to the architect.
Can I shrink a volume later?
No. STACKIT documents that the capacity of an existing volume cannot be reduced. Add a smaller volume, copy the data and remove the larger one.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.