VMware Troubleshooting
vSphere IDs: The Ultimate Quick Reference Guide | Lazy Admin Blog
Ever feel like you’re drowning in a sea of GUIDs and MoRefs? When you’re scripting or troubleshooting, using the wrong ID is the fastest way to break a backup job or target the wrong server.
Here is the “Lazy Admin” breakdown of the most common vSphere identifiers and how to grab them with PowerCLI.
1. vCenter Instance UUID (serverGuid)
This is the “SSN” of your vCenter server. It’s generated at install time and stays durable for that instance.
- Why it matters: In Linked Mode or cross-vCenter environments, this identifies which vCenter owns an object.
- PowerCLI:PowerShell
$vcenter = Connect-viserver vcsa-01a.corp.local $vcenter.InstanceUuid
2. ESXi Host UUID
Unlike other IDs, this isn’t generated by VMware. It’s pulled from the hardware’s SMBIOS.
- Why it matters: It’s unique to the physical motherboard/vendor.
- PowerCLI:PowerShell
(Get-VMHost | Select -First 1).ExtensionData.hardware.systeminfo.uuid
3. VC-VM Instance UUID (The “Management” ID)
Found in the .vmx file as vc.uuid. This is what vCenter uses to track VMs.
- The “Magic”: vCenter actively scans for duplicates of this ID and will “patch” (change) it automatically if it finds a conflict within its own inventory.
- PowerCLI:PowerShell
(Get-VM | Select -First 1).extensiondata.config.InstanceUUID
4. VM SMBIOS UUID (The “Guest” ID)
Found as uuid.bios in the .vmx. This is what the Guest OS (Windows/Linux) sees as the hardware serial number.
- The “Magic”: vCenter tries not to change this because many applications use it for licensing. If you move/copy a VM, vCenter will ask you what to do to prevent duplicates.
- PowerCLI:PowerShell
(Get-VM | Select -First 1).extensiondata.Config.UUID
5. VM Location ID
Stored as uuid.location. This is a hash of the VM’s configuration file path and the ESXi host UUID.
- The “I Moved It” Prompt: When this hash doesn’t match the current environment, vSphere triggers that famous “Did you move it or copy it?” popup.
- PowerCLI:PowerShell
(Get-VM | Select -First 1).extensiondata.config.LocationId
6. VM MoRef (Managed Object Reference)
The MoRef is the “Short ID” (like vm-43) used by the API and the vCenter database.
- Why it matters: This is the most important ID for database associations (stats, events, tasks). It is not unique across different vCenters.
- PowerCLI:PowerShell
(Get-VM | Select -First 1).ExtensionData.Moref.Value
Quick ID Reference Table
| ID Name | Scope | Persistence | Best Use Case |
| MoRef | Single vCenter | Changes if re-inventoried | API calls & DB tracking |
| Instance UUID | Single vCenter | High (Patched by VC) | Unique VM tracking |
| SMBIOS UUID | Global/Guest OS | Very High | Guest Software Licensing |
| Host UUID | Physical Hardware | Permanent | Hardware Asset Tracking |
Dealing with ESXi: “Lost connectivity to the device backing the boot filesystem” | Lazy Admin Blog
Meta Description: Seeing the “naa.60xxx backing the boot filesystem” error in ESXi? Learn why your VMs are safe and how to clear this persistent alert without a full reboot.
The Scenario
You open your vCenter console to find a critical alert screaming at you:
Lost connectivity to the device naa.60xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx backing the boot filesystem /vmfs/devices/disks/naa.60xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. As a result, host configuration changes will not be saved to persistent storage.
For any SysAdmin, “Lost Connectivity” and “Boot Filesystem” in the same sentence is usually a reason to start reaching for the coffee and the backup tapes. But before you initiate an emergency failover, let’s look at what is actually happening.
Why did this happen?
If you are booting from a SAN (specifically using iSCSI boot), your ESXi host relies on a connection to a Boot LUN. Unlike your data datastores, iSCSI boot does not support Multipathing.
If a switch reboots, a cable is bumped, or the Storage Processor (SP) on your array (like a VNXe) fails over, the single path to that boot device is severed. Even if the hardware recovers a second later, the ESXi “heartbeat” to the boot device has been interrupted.
The “Lazy” Good News: No Outage
Here is the secret: ESXi is a resident-in-memory OS. Once the host has finished booting, the entire kernel is loaded into RAM. Because the VMs are running on different datastores (which should have multipathing), they will continue to hum along without a hiccup.
The Risk: The only thing you can’t do while this error is active is save configuration changes. If you change a vSwitch setting or a license key, it won’t be written to the “disk” (the LUN), and it will be lost if the host reboots.
The Fix: Clear the Ghost Alert
Often, once connectivity is restored, ESXi doesn’t realize the path is back. You have two ways to fix this:
1. The “Smart” Fix (No Downtime)
Instead of a full reboot, you can simply restart the Management Agents. This force-refreshes the host’s connection to its management services and the underlying boot filesystem.
Via DCUI:
- Connect to the console of your ESXi host.
- Press F2 to customize the system.
- Select Troubleshooting Options.
- Select Restart Management Agents.
Via SSH: Run the following command: services.sh restart
2. The “Maintenance” Fix
If the agents don’t clear the alert, you’ll need a clean slate:
- vMotion your VMs to another host.
- Put the host into Maintenance Mode.
- Reboot the host.
Summary for the Modern SysAdmin
- Is there an outage? No.
- Can I save changes? Not until fixed.
- Why? iSCSI boot has no multipathing.
- Quick Fix: Restart Management Agents.
Finding RDM LUN UUIDs in a vSphere Cluster | Lazy Admin Blog
If you’re managing a large virtual environment, keeping track of Raw Device Mappings (RDMs) can be a nightmare. Unlike standard virtual disks (VMDKs) that live neatly inside a datastore, RDMs are directly mapped to a LUN on your SAN.
When your storage team asks, “Which VM is using LUN ID 55?”, you don’t want to check every VM manually. This PowerCLI script will scan your entire cluster and export a list of all RDMs along with their Canonical Name (NAA ID) and Device Name.
The PowerCLI One-Liner
This command connects to your cluster, filters for disks that are either RawPhysical (Pass-through) or RawVirtual, and spits out the details to a text file for easy searching.
Run this in your PowerCLI window:
PowerShell
Get-Cluster 'YourClusterName' | Get-VM | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select-Object @{N="VM";E={$_.Parent.Name}},Name,DiskType,ScsiCanonicalName,DeviceName | Format-List | Out-File –FilePath C:\temp\RDM-list.txtBreaking Down the Output
Once you open C:\temp\RDM-list.txt, here is what you are looking at:
- Parent: The name of the Virtual Machine.
- Name: The label of the hard disk (e.g., “Hard disk 2”).
- DiskType: Confirms if it’s Physical (direct SCSI commands) or Virtual mode.
- ScsiCanonicalName: The NAA ID (e.g.,
naa.600601...). This is the “Universal ID” your storage array uses. - DeviceName: The internal vSphere path to the device.
Why do you need this?
- Storage Migrations: If you are decommissioning a storage array, you must identify every RDM to ensure you don’t leave a “Ghost LUN” behind.
- Troubleshooting Performance: If a specific LUN is showing high latency on the SAN side, this script tells you exactly which VM is the “noisy neighbor.”
- Audit & Compliance: Great for keeping a monthly record of physical hardware mappings.
Lazy Admin Note: This script specifically uses VMware PowerCLI cmdlets (
Get-HardDisk). If you are looking for similar info on a Hyper-V host, you would typically useGet-VMHardDiskDriveand look for theDiskNumberproperty to correlate with physical disks inDisk Management.