Thirty tabs, and the twelve columns that decide your project
An RVTools workbook contains more detail than anyone reads. Most of it is reference material you will never open. A small subset determines what you get billed and how hard the migration is, and it is not the subset most people look at first.
Read it in this order
Not tab order. Question order, because each answer changes how you read the next tab:
- vHealth first. Before you trust a single number in the workbook, find out how much of it is garbage. Orphaned VMs, zombie VMDKs, and VMs on inaccessible datastores all inflate capacity and VM counts. Clean the numbers before you build a business case on them.
- vHost second. Total physical cores is your licensing exposure and the number that makes the financial case. It is a two-minute sum and it is the figure the whole project turns on.
- vInfo third. Now you know the estate is real, count it. Split powered-on from powered-off immediately; powered-off VMs are scope you can decommission rather than migrate, and that decision is free money.
- vDisk, vSnapshot, vUSB, vCD fourth. The blocker sweep. This is where a clean-looking estate turns out to have fourteen VMs that need individual attention.
- Everything else on demand. The remaining tabs answer specific questions when they come up. Do not read them front to back.
The one number people get wrong
vCPUs are not cores. vInfo reports vCPUs allocated to virtual machines, a number inflated by overcommitment and typically several times larger than the physical core count. vHost reports physical cores in the hosts, which is what per-core subscription licensing bills against, subject to the per-CPU core minimum.
We have seen this mistake in both directions: teams panicking at a renewal quote modeled against vCPUs, and teams under-budgeting because they counted sockets rather than cores. Sum vHost physical cores, apply the core floor per CPU, and use that figure in the cost calculator and the renewal estimate. The analyzer does this calculation from the workbook so the mistake cannot happen.
Tab by tab
What each worksheet holds, and the specific reason a migration cares about it. Tab names vary slightly across RVTools versions; the content is stable.
vInfo · One row per virtual machine: power state, guest OS, vCPU and memory allocation, provisioned and used storage, folder, resource pool, VMware Tools state, and the VM's own config-file path.
Why it matters on the way out: The spine of the whole workbook. Everything else joins back to it. It is also where powered-off VMs become visible as scope you can delete rather than migrate.
vHost · One row per ESXi host: model, CPU sockets, physical cores per socket, total cores, memory, build number, cluster membership, and current VM count.
Why it matters on the way out: Physical core count summed across hosts is the number per-core subscriptions bill against. This tab, not the VM count, is your licensing exposure.
vCPU / vMemory · Per-VM CPU and memory detail: allocations, reservations, limits, shares, hot-add settings, and ballooned or shared memory.
Why it matters on the way out: Reservations and limits are configuration that has to be recreated by hand on the target platform. Hot-add is not universally supported after a move.
vDisk · One row per virtual disk: capacity, thin or thick provisioning, disk mode, controller, the backing datastore, and the disk's file path.
Why it matters on the way out: Where raw device mappings, independent-mode disks, and shared-bus configurations surface. These are the hard blockers, they do not convert cleanly and each one needs an owner.
vPartition · Guest-visible partitions with capacity and free space, as reported by VMware Tools.
Why it matters on the way out: Distinguishes provisioned from actually consumed capacity, which is what you should be sizing the target platform against rather than the provisioned total.
vSnapshot · Every snapshot on every VM, with its name, description, creation date, and size.
Why it matters on the way out: Open snapshot chains, especially old ones, are both a migration hazard and free capacity. A two-year-old snapshot is almost always forgotten rather than intentional.
vNetwork · Per-VM network adapters: adapter type, connected port group, MAC address, IP addresses, and connection state.
Why it matters on the way out: Adapter types and MAC handling differ across hypervisors. Static MAC dependencies and hardcoded IPs are the usual cause of a VM that boots after migration but cannot be reached.
vUSB · USB devices and controllers attached to VMs, including passthrough devices.
Why it matters on the way out: USB passthrough, typically a licensing dongle, is a physical dependency that almost never survives a migration without a plan for it.
vCD · Virtual CD/DVD drives and what is mounted to them.
Why it matters on the way out: Mounted ISOs block some migration operations and are trivially fixed in advance. Pure free wins, worth clearing before the project starts.
vHost / vCluster · Cluster configuration: HA and DRS settings, admission control policy, EVC mode, and per-cluster host membership.
Why it matters on the way out: EVC mode tells you the CPU generation floor you are actually running at, which constrains what target hardware you can land on.
vDatastore · Datastores with capacity, free space, type (VMFS, NFS, vSAN), and the hosts attached to each.
Why it matters on the way out: Determines whether you have room to stage a migration in place, and vSAN in particular changes the storage story on the way out significantly.
vHealth · RVTools' own checks: zombie VMDKs, orphaned VMs, inconsistent folder paths, VMs on inaccessible datastores, and similar inventory hygiene problems.
Why it matters on the way out: Read this before you cost anything. Zombie disks and orphaned VMs inflate every capacity number in the workbook and will inflate your migration quote too.
vLicense · Licenses registered in vCenter with their key, edition, capacity, and consumption.
Why it matters on the way out: The starting point for what you are entitled to today versus what a subscription renewal proposes to sell you.
vTools · VMware Tools version and running state per VM.
Why it matters on the way out: Out-of-date or not-running Tools degrades the fidelity of guest-reported data elsewhere in the workbook, and Tools has to be replaced with the target platform's equivalent on every VM.
What the export cannot tell you
This is the honest limit of an inventory-driven assessment, and it is worth saying out loud before someone builds a migration plan that assumes the workbook is complete.
- Application dependencies. RVTools sees VMs, not the fact that three of them are one application and must cut over together. No inventory export will give you this; it comes from talking to service owners.
- Backup and DR coupling. Which VMs are protected by which job, and what breaks when the VM moves platform, lives in your backup product, not in vCenter.
- Network micro-segmentation. NSX policy is not represented in a standard export. If you run NSX, that is a separate discovery exercise and often the longest pole in the migration.
- vGPU and SR-IOV passthrough. These do not appear reliably in the export. Check them by hand in vCenter, because a GPU-attached VM has a very different set of destination options.
- Licensing inside the guest. Software licensed to a host ID, MAC address, or CPU signature will break on migration and is invisible from the hypervisor's point of view.
Our per-path guides cover how each of these is handled on the way to a specific target: Proxmox VE, XCP-ng, Hyper-V, and Nutanix AHV.
Frequently asked
Which RVTools tab shows CPU cores for licensing?
vHost. Sum the physical cores across all hosts, applying the per-CPU core minimum your licensing terms impose. vInfo shows vCPUs allocated to virtual machines, which is a different and much larger number, and is not what per-core subscriptions bill against. Confusing the two is the most common and most expensive mistake made when reading an export.
What is the difference between provisioned and used storage in vInfo?
Provisioned is the sum of the virtual disk sizes as configured. Used ('in use') is what is actually consumed on the datastore, which is lower wherever disks are thin-provisioned. Size a target platform against consumed capacity plus growth, not against provisioned, or you will buy storage for data that does not exist.
How do I find raw device mappings in an RVTools export?
vDisk, in the raw device mapping columns. RDMs point a VM at a LUN rather than a VMDK, so there is no file to convert, which makes them a hard blocker: every RDM needs a decision about how that storage is presented on the target platform before the VM can move.
Why do some columns come back empty?
Usually one of three reasons: VMware Tools is not running in the guest, so guest-reported fields such as IP addresses and partition usage are unavailable; the account lacks visibility to that part of the inventory; or the RVTools version predates the vSphere API that supplies the field. The first is by far the most common.
Can I just look at vInfo and skip the rest?
For a VM count, yes. For a migration, no. Every blocker that changes the cost and duration of the project lives outside vInfo: RDMs and shared-bus disks on vDisk, passthrough on vUSB, snapshot chains on vSnapshot, and inventory hygiene on vHealth. A scope built from vInfo alone is a scope that gets revised upward mid-project.
Does RVTools show fault-tolerant VMs?
Yes, FT state is reported per VM. FT pairs are worth flagging early because fault tolerance as vSphere implements it has no direct equivalent on most target platforms, so those workloads need an availability design rather than a lift and shift.