Reading RVTools vInfo, vDisk and vNetwork data for a STACKIT migration

The walk-through in six steps

1. 01

   Put the sheets in one folder

   Export the RVTools sheets as CSV files into one folder, or keep the .xlsx workbook. The demo folder holds RVTools_tabvInfo.csv, RVTools_tabvDisk.csv and RVTools_tabvNetwork.csv. If the input type is not detected, add --input rvtools.

2. 02

   Run the assessment

   stacktoit assess ./rvtools-export ./vmware-migration reads the files on your computer. Nothing is installed in the VMware environment and StackToIT does not connect to vCenter.

3. 03

   Start with the architect report

   engineering/architect-report.md lists every unit with class, findings and open settings, and names the rows the run could not place. index.html shows the same per unit.

4. 04

   Follow one VM across the sheets

   A vInfo row becomes a unit named vm.<name>. Its vDisk rows become the boot volume and further volumes, its vNetwork rows become network interfaces. The next four sections show this on real rows.

5. 05

   Read what did not match

   A detail row that names no VM of vInfo is reported with its row number. It is a source gap, and the draft waits until it is resolved.

6. 06

   Answer the open settings and run again

   What the export cannot state, such as machine types, subnet prefixes and DNS servers, goes into the files in review/. The next run reads them.

vDisk: capacity in MiB becomes size in GiB

A seven-machine export written for this page and assessed by StackToIT on 4 November 2026. Left: the two vDisk rows of erp-app01. Right: the resource blocks of the STACKIT Terraform the engine wrote for them; the comment lines above each block in the file are left out here.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
erp-app01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[ds-prod-01] erp-app01/erp-app01.vmdk,5001-aaaa-0001
erp-app01,Hard disk 2,143360,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[ds-prod-01] erp-app01/erp-app01_1.vmdk,5001-aaaa-0001

resource "stackit_server" "vm_erp_app01" {
  project_id        = var.project_id
  name              = "erp-app01"
  machine_type      = var.vm_erp_app01_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type = "image"
    source_id   = var.vm_erp_app01_image_id
    size        = 60
  }
  network_interfaces = [stackit_network_interface.vm_erp_app01_nic1.network_interface_id]
}

resource "stackit_volume" "vm_erp_app01_disk2" {
  project_id        = var.project_id
  name              = "erp-app01-disk2"
  availability_zone = var.availability_zone
  size              = 140
  performance_class = var.vmware_volume_performance_class
}

• Hard disk 1 is the boot volume

  61440 MiB is 60 GiB. The server starts from an image that you convert from this disk, and the boot volume is sized 60.

• Every further disk is a volume

  Hard disk 2, 143360 MiB, becomes a 140 GiB volume. The comment in the file says its data is copied after the volume exists: the draft plans the volume, not the copy.

• The machine type stays yours

  CPUs and Memory of vInfo (4 and 16384) appear only in the description of the machine type variable, as 4 vCPU and 16 GiB. You choose the STACKIT type.

vDisk: a raw device ends the automatic path

From the same run. Left: the three disks of erp-db01, the last one with Raw = True on a physicalSharing bus. Right: the part of assessment.json that records the decision for that VM (finding identifiers left out).

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
erp-db01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-prod-02] erp-db01/erp-db01.vmdk,5001-aaaa-0002
erp-db01,Hard disk 2,512000,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[ds-prod-02] erp-db01/erp-db01_1.vmdk,5001-aaaa-0002
erp-db01,Hard disk 3,512000,True,persistent,sharingNone,False,SCSI controller 2,physicalSharing,[ds-san-01] erp-db01/erp-db01_rdm.vmdk,5001-aaaa-0002

{
  "id": "vm.erp-db01",
  "result": {
    "class": "MANUAL_REVIEW",
    "confidence": "MEDIUM",
    "findings": [
      {
        "severity": "critical",
        "message": "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."
      },
      {
        "severity": "critical",
        "message": "Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). Shared block storage for several servers is not verified on STACKIT in this knowledge base; the cluster design has to be reviewed."
      },
      {
        "severity": "info",
        "message": "Not verifiable statically (snapshots not visible): The VM has snapshots; consolidate them before export — only the current state is migrated."
      }
    ]
  }
}

• Class changes to manual review

  erp-db01 is the only one of the seven machines classified MANUAL_REVIEW, and compute.tf has no server block for it.

• Two findings from one row

  The same third disk raises a raw-device finding and a shared-disk finding, because Shared Bus is physicalSharing. Read both before you plan the copy.

• Why it matters

  A raw LUN is not inside the VMDK files, so an image export does not carry its data. The finding asks for a block-level or application-level copy to a STACKIT volume.

vNetwork: one row per adapter

From the same run. Left: the two adapter rows of gw-edge01. Right: the network interfaces the engine wrote for them.

VM,NIC label,Adapter,Network,Switch,Connected,IPv4 Address,VM UUID
gw-edge01,Network adapter 1,Vmxnet3,PG-Edge,dvs-edge,True,192.0.2.10,5001-aaaa-0005
gw-edge01,Network adapter 2,Vmxnet3,PG-ERP-App,dvs-erp,True,10.40.10.1,5001-aaaa-0005

resource "stackit_network_interface" "vm_gw_edge01_nic1" {
  project_id = var.project_id
  network_id = stackit_network.network_PG_Edge.network_id
  ipv4       = "192.0.2.10"
}

resource "stackit_network_interface" "vm_gw_edge01_nic2" {
  project_id = var.project_id
  network_id = stackit_network.network_PG_ERP_App.network_id
  ipv4       = "10.40.10.1"
}

• The Network column picks the network

  PG-Edge and PG-ERP-App are two port groups, so the two interfaces point at two different STACKIT networks.

• IPv4 Address is kept

  Both interfaces carry the address from the export. An adapter with an empty address, like the one of arch-old01, gets an interface without a fixed address.

• The switch is not carried

  dvs-edge and dvs-erp are distributed switches. The run lists the switch among the properties the draft does not carry, because a STACKIT network has no counterpart for it.

One stray vDisk row and no draft

Our first run of this estate had one extra row in the vDisk sheet, for a machine that is not in vInfo. Left: that row. Right: what the run recorded about it, from assessment.json.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
retired-vm09,Hard disk 1,51200,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[ds-prod-01] retired-vm09/retired-vm09.vmdk,5001-aaaa-0099

{
  "summary": {
    "source_status": "RVTOOLS_DETAIL_UNMATCHED",
    "source_file_gaps": [
      {
        "path": ".#vDisk",
        "kind": "RVTOOLS_DETAIL_UNMATCHED",
        "detail": "1 of 11 vDisk rows could not be attributed to exactly one vInfo VM (match rate 10/11); they are attached to no VM: row 12 VM \"retired-vm09\": no VM of vInfo has the name \"retired-vm09\" with the UUID 5001-aaaa-0099"
      }
    ],
    "blocked_outputs": [
      {
        "output": "STACKIT draft (terraform/)",
        "reason": "a source file was not read in full (summary.source_file_gaps); no STACKIT draft is generated from a source that was not seen in full"
      },
      {
        "output": "migration waves (migration/technical-sequencing.md, units[].wave)",
        "reason": "a source file was not read in full (summary.source_file_gaps); a wave orders the whole estate and what is missing may hold units and dependencies"
      }
    ]
  }
}

• Nothing was drafted

  All 12 units were assessed, but the run wrote no Terraform and no waves, because it does not draft from a source it did not see in full.

• The message names the row

  It states the sheet, the row, the VM name and the UUID that matched nothing, and the match rate of 10 of 11 rows.

• Remove the row and run again

  With that row deleted, the same estate produced the draft: 10 units generated, 2 left for the architect, 24 variables. All other snippets on this page come from that second run.

Which column decides what

Without the vSnapshot and vMemory sheets the run warns that snapshots and memory reservation of the 7 VMs are unknown, not none. Add both sheets to the export.

Before you run: make the export join cleanly

• Export all sheets in one RVTools run

  A disk added between two exports is a row without a matching machine. One run, one moment, one set of files.

• Every vDisk and vNetwork row names a VM of vInfo

  Name and, where stated, UUID must belong to the same machine. The run reports a mismatched row with its sheet, row number, name and UUID.

• Keep vSnapshot and vMemory in the export

  They turn unknown snapshots and reservations into stated ones. The backup checklist for VMware estates builds on them.

• Decide about templates and powered-off machines

  They are assessed like any other row. Decide early which ones you keep, so the review queue shows the machines that matter.

• Read a run with gaps anyway

  The units and their classes are written even when the draft is withheld, so you can already see raw devices, end-of-support guests and multi-adapter machines.

Questions about the RVTools sheets

Sources

• StackToIT docs: VMware to STACKIT
• STACKIT docs: Machine types
• STACKIT docs: Use custom images with the IaaS API