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.

Example inputRVTools_tabvDisk.csv
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-0004
STACKIT Terraform by StackToITterraform/compute.tf
resource "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 diskSource (vDisk)Draft
sz-small01, Hard disk 120480 MiBboot volume 20 GiB
sz-odd01, Hard disk 151201 MiBboot volume 51 GiB
sz-mem01, Hard disk 1 and 2102400 MiB and 512000 MiBboot volume 100 GiB, volume 500 GiB
sz-big01, Hard disks 1 to 361440, 1048576 and 2086528 MiBboot volume 60 GiB, volumes 1024 and 2038 GiB
sz-snap01, Hard disk 161440 MiBboot 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. 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.

  2. 1:4, general purpose (family g)

    sz-big01 (16 vCPU, 64 GiB) and, by its source size, sz-rdm01 (4 vCPU, 16 GiB).

  3. 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.

  4. 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.

Example inputRVTools_tabvMemory.csv
VM,Size MiB,Reservation,VM UUID
sz-mem01,131072,131072,4208-dddd-0003
sz-odd01,12288,0,4208-dddd-0002
Manual stepexecution/manual/actions.md
      - 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.