VMWARE → STACKIT · STORAGE
Planning VMFS and vSAN storage for the move to STACKIT
RVTools names the datastore of every VM and disk in its paths, but it does not say whether that datastore is VMFS or vSAN and it carries no vSAN policy. StackToIT therefore drafts every data disk as a volume of the same size with one performance-class variable. Storage planning for STACKIT is a short inventory per datastore and one decision per tier, and this page shows both on a seven-VM demo estate.
Storage planning in five steps
Read the datastores
Every disk row of the vDisk sheet carries a path that starts with the datastore in square brackets. The vInfo sheet does the same for the VM's configuration file. The run records the bracketed name as the datastore of the VM and, per disk, as the datastore of that disk, and hands both back as settings to decide.
Total them per datastore
Add up the provisioned capacity and count VMs per datastore. A datastore is usually a tier: the same hardware, the same policy, the same owner.
Give each tier a performance class
STACKIT picks the performance class when you create a volume. Decide per tier which class it needs, from measured IOPS and throughput on the source, not from the datastore name.
Check the volume rules
A data volume holds 1 GB to 16 TB, attaches to one server at a time and can grow only while detached. A Single AZ volume is fixed to one availability zone and not mirrored across zones; a Metro volume is mirrored across two zones.
Choose how the data moves
The run lists the volumes; it never copies a byte. Pick a method per tier from the size and the downtime the application tolerates.
The demo estate in the vDisk sheet
A demo estate written for this page and assessed by StackToIT on 4 November 2026: three port groups, seven VMs on three datastores. Left: the whole vDisk sheet. Right: the data volume the run drafts for the large disk of arch-fs01; 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
crm-web01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-web01/crm-web01.vmdk,4204-d010-0001
crm-app01,Hard disk 1,81920,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-app01/crm-app01.vmdk,4204-d010-0002
crm-app01,Hard disk 2,204800,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-app01/crm-app01_1.vmdk,4204-d010-0002
crm-db01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[vmfs-ssd-db] crm-db01/crm-db01.vmdk,4204-d010-0003
crm-db01,Hard disk 2,819200,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd-db] crm-db01/crm-db01_1.vmdk,4204-d010-0003
crm-db02,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[vmfs-ssd-db] crm-db02/crm-db02.vmdk,4204-d010-0004
crm-db02,Hard disk 2,819200,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd-db] crm-db02/crm-db02_1.vmdk,4204-d010-0004
arch-fs01,Hard disk 1,51200,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-nl-archive] arch-fs01/arch-fs01.vmdk,4204-d010-0005
arch-fs01,Hard disk 2,18432000,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl-archive] arch-fs01/arch-fs01_1.vmdk,4204-d010-0005
bkp-proxy01,Hard disk 1,40960,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] bkp-proxy01/bkp-proxy01.vmdk,4204-d010-0006
batch01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] batch01/batch01.vmdk,4204-d010-0007
batch01,Hard disk 2,1048576,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl-archive] batch01/batch01_1.vmdk,4204-d010-0007resource "stackit_volume" "vm_arch_fs01_disk2" {
project_id = var.project_id
name = "arch-fs01-disk2"
availability_zone = var.availability_zone
size = 18000
performance_class = var.vmware_volume_performance_class
}
resource "stackit_server_volume_attach" "vm_arch_fs01_disk2" {
project_id = var.project_id
server_id = stackit_server.vm_arch_fs01.server_id
volume_id = stackit_volume.vm_arch_fs01_disk2.volume_id
}Capacity is carried, the datastore is not
The volume has size 18000, the capacity of the source disk in GiB, and the shared performance-class variable. Which datastore the disk came from does not reach the file.
The draft does not warn about the size
18000 GiB is about 17.6 TiB. The STACKIT concepts page gives 16 TB as the largest data volume. The run drafted the block without a finding on this, so check disk sizes against that limit yourself.
The estate by datastore
Computed from the vDisk sheet above. The datastore names are the demo's own; in your export they are whatever your paths say.
| Datastore | VMs and disks | Provisioned |
|---|---|---|
| vsan-prod | 4 VMs, 5 disks: crm-web01, crm-app01 (2), bkp-proxy01, batch01 boot disk | 440 GiB |
| vmfs-ssd-db | 2 VMs, 4 disks, all thick: crm-db01 and crm-db02 with 100 GiB and 800 GiB each | 1800 GiB |
| vmfs-nl-archive | 2 VMs, 3 disks: arch-fs01 (50 GiB and 18000 GiB), batch01 data disk (1024 GiB) | 19074 GiB |
| Whole estate | 7 VMs, 12 disks | 21314 GiB |
batch01 lives on two tiers: its boot disk is on vsan-prod and its data disk on vmfs-nl-archive. The run records the datastore per disk for exactly that reason.
What the run hands back as a decision
From the action list of the same run. Both settings go to the Platform Architect, and the variable below is the single performance class the draft applies to every data volume.
- `datastore` (Platform Architect; decision register record DEC-OPS-VM-ARCH-FS01)
- 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. The datastore (the [name] prefix of the vInfo Path) carries the storage tier; the draft takes stackit_volume.performance_class from the variable vmware_volume_performance_class, so the source placement is a person's input, not carried.
- Done when: A person confirms the value against the target, or the knowledge base gains a rule that decides this setting.
- `disk-datastore` (Platform Architect; decision register record DEC-OPS-VM-ARCH-FS01)
- 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. Each disk's datastore says which performance class its volume needs; the draft applies one performance-class variable to every data disk, so the per-disk placement is not carried.variable "vmware_volume_performance_class" {
type = string
description = "STACKIT block-storage performance class for migrated VM data disks."
}One variable for all tiers
The draft applies one class to every migrated data disk, so a database tier and an archive tier come out identical until you edit the volume blocks or split the variable.
The value is yours
The source says nothing about IOPS, and the run does not guess. Fill the variable with a class from the STACKIT service plans page.
VMware storage against STACKIT volumes
| Topic | VMware side | STACKIT side |
|---|---|---|
| Protection of the data | On vSAN, the storage policy sets Failures to tolerate: n failures mean n+1 places for each piece of data, and a 100 GB object consumes 200 GB with RAID-1. On VMFS it depends on the storage system underneath, which RVTools does not see. | Encrypted at rest with AES-256; snapshots and full and incremental backups exist for volumes. Protection is chosen by setup, not by a policy: Single AZ data is not mirrored across zones, Metro data is mirrored across two zones. No copy count comparable to FTT is stated. |
| Capacity to plan for | On vSAN, consumed capacity includes the policy overhead: 100 GB with RAID-1 at FTT 1 consume 200 GB. | Size from the provisioned capacity of the VM disks, not from datastore usage. |
| Performance | Set by the tier or the policy of the datastore. | A performance class per volume, independent of size. perf2 lists 1000 IOPS and 100 MB/s, perf6 lists 5000 IOPS and 200 MB/s; the page continues to higher classes. |
| Sharing | Multi-writer disks on VMFS or vSAN. | No multi-attach; one data volume belongs to one server. |
| Resizing | Disks can be grown and thin disks stay small. | Grow only while detached; no shrinking. Drafted sizes equal source capacity. |
| Largest disk | Whatever the source disk has; the demo has an 18000 GiB disk. | 1 GB to 16 TB per data volume. |
Backup retention, snapshot limits and how a Metro volume is selected are not stated in the pages this guide uses, and the service plans page lists performance figures for the eu01 region only; confirm them for the region you target.
Decisions that stay with the architect
Tier to class
Map vsan-prod, vmfs-ssd-db and vmfs-nl-archive to three classes, or to one. Measure the busiest hour on the source before deciding.
Size from provisioned or from used
The vInfo sheet lists provisioned and in-use MiB per VM. Volumes cannot shrink, so a thin disk provisioned at 1024 GiB but half empty deserves a smaller volume that you grow when needed.
The 18000 GiB disk
It exceeds the volume maximum. Split the content across volumes at application level, or replace the file server with an object store or file service; the run cannot decide this for you.
VMs spread across tiers
batch01 needs a different class for its data volume than for its boot volume. The single variable cannot express that.
Snapshots on bkp-proxy01 and crm-app01
The run reports snapshots on both. Consolidate before the final copy; only the current state migrates.
How the data moves
Common methods are a block copy of the disk, a file-level sync such as rsync, or an application-level copy such as database replication. This is practice, not something the run chooses or runs.
Questions about VMFS, vSAN and STACKIT
Does the run tell VMFS from vSAN?
No. It reads the datastore name from the path and has no datastore type, no vSAN policy and no capacity of the datastore. Keep that inventory from vCenter.
Does the vSAN policy have an equivalent on STACKIT?
Not as a policy. FTT and RAID-5/6 are vSAN settings. On STACKIT you choose a performance class per volume and a Single AZ or Metro setup: Single AZ data is not mirrored across zones, Metro data is mirrored across two. For data that needs zone redundancy, Metro is the documented option; backups are a separate decision.
Why does the draft use one performance class?
Because the export does not say what each disk needs. The run states this itself and leaves the per-disk choice to a person.
Where do I see the datastore decision?
In execution/manual/actions.md, under the settings datastore and disk-datastore of each VM, and in the decision register of the run.
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.