When the export fails, or quietly succeeds badly
Most RVTools failures are environmental rather than defects in the tool, which is good news because it means they are all fixable from your side. The dangerous ones are not the errors, they are the exports that complete cleanly while missing half your estate.
Check this before you troubleshoot anything
Compare the host count and VM count in the export against what you know you run. If they disagree, you do not have a tool problem, you have a permission-scope problem, and every number in the workbook is understated. A silently incomplete export that gets used to build a migration budget is a far more expensive failure than one that throws an error and stops.
Symptom, cause, fix
Login fails, but the same credentials work in the vSphere Client
What is happening: Almost always the account format or the identity source rather than the password. vCenter accepts several principal formats and RVTools passes through exactly what you type.
Fix: Try the full user principal name ([email protected]) rather than DOMAIN\user, and confirm the account is a member of an SSO identity source vCenter actually trusts. If the account is local to the appliance, it needs the @vsphere.local suffix. Also check the account is not locked out from earlier attempts.
A certificate or TLS handshake error on connect
What is happening: The vCenter certificate does not match the name you connected to, or it chains to a private CA the Windows machine running RVTools does not trust.
Fix: Connect using the exact FQDN in the certificate subject, not an IP address or a short hostname. If your vCenter uses an internal CA, install that CA certificate into the Trusted Root store on the machine running RVTools. Disabling certificate validation is offered by some tooling and is the wrong answer here, you are about to type privileged credentials into the connection.
It connects, but whole worksheets come back empty
What is happening: Permission scope, not a bug. The read-only role was granted on a folder, cluster, or datacenter rather than at the vCenter root, so RVTools can only see part of the tree.
Fix: Assign Read-only at the root of the inventory with propagation to child objects, then re-run. This is the single most common cause of an export that looks successful but is missing hosts, datastores, or entire clusters.
Guest-level columns are blank: IP addresses, hostnames, partition usage
What is happening: Those fields come from VMware Tools inside the guest, not from the hypervisor. No Tools, or Tools not running, means no data.
Fix: Check the vTools worksheet. Where Tools is absent or stopped, the blanks are expected and accurate, the data genuinely is not available. Do not treat these VMs as decommissioned; cross-reference power state on vInfo first.
The collection hangs or times out on a large estate
What is happening: RVTools gathers everything before rendering, and on several thousand VMs that is a long sustained run of API queries. A busy or undersized vCenter appliance makes it longer.
Fix: Run it outside backup and change windows, from a management host with a low-latency path to vCenter. If it consistently fails, export in stages by connecting to individual vCenters rather than through Enhanced Linked Mode, then combine the workbooks.
The export is truncated, or Excel complains when opening it
What is happening: Worksheet row ceilings. A very large estate, particularly on vDisk and vPartition where each VM contributes several rows, can approach the limits of the spreadsheet format.
Fix: Export to CSV instead of xlsx for the oversized worksheets, and analyze them with something that does not load the whole file into memory. If you only need the migration-relevant subset, this is a good point to switch to a tool that parses the workbook directly.
Columns you remember are missing after upgrading vCenter
What is happening: Version skew. An older RVTools build queries API properties that moved or were renamed in a newer vSphere release, and returns nothing for them.
Fix: Update RVTools to a build tested against your vSphere version. This is also worth checking whenever a workbook disagrees with the vSphere Client about something you can verify by hand.
It worked last month from the same machine and now it does not
What is happening: Usually credential expiry, a rotated service-account password, or a certificate renewal on the vCenter appliance. Occasionally a Windows update changed the available TLS ciphers.
Fix: Check password expiry on the service account first, then the vCenter certificate validity dates. Both fail in ways that look like a tool problem and are not.
A note on the "just disable certificate checking" advice
You will find this suggested in forum threads for the TLS errors above. It resolves the symptom and is the wrong trade. The connection you are about to make carries a vCenter credential, and certificate validation is the only thing confirming that the host answering on port 443 is the vCenter you think it is. Installing your internal CA certificate into the Trusted Root store takes about the same amount of time and does not leave a management workstation configured to trust anything.
This matters more than usual for RVTools specifically, given the supply-chain incident covered on is RVTools safe to run. A toolchain where verification has been switched off in two places is a toolchain where the third thing goes unnoticed.
Frequently asked
Why does RVTools say the export succeeded when data is missing?
Because from the tool's perspective it did. RVTools reports what the API returned for the account it authenticated as. If the account cannot see a cluster, the API returns nothing for it and that is not an error condition. Always sanity-check the host and VM counts in the export against what you know you run before trusting the workbook.
Can I run RVTools against multiple vCenters at once?
Connect to one at a time and combine the exports. Enhanced Linked Mode environments can behave inconsistently on large collections, and separate exports are easier to sanity-check anyway because you can verify each vCenter's counts independently.
Is a failed export ever a sign of a problem with vCenter itself?
Occasionally, yes. Persistent timeouts on an estate that used to export fine can indicate an undersized or struggling vCenter appliance, and inventory inconsistencies reported on vHealth sometimes reflect real database problems rather than reporting artifacts. If the export degrades over time rather than failing outright, that is worth investigating on its own.
Do I need to disable antivirus to run RVTools?
No, and you should not. If your endpoint protection flags an RVTools installer, treat that as a signal worth investigating rather than an obstacle to suppress: a trojanized RVTools installer was distributed in May 2025. See our page on whether RVTools is safe to run.