Datastore

The Clean Exit: How to Safely Remove Storage Devices from ESXi | Lazy Admin Blog

Posted on Updated on

In the world of storage, “unpresenting” a LUN is more than just a right-click. If you don’t follow the proper decommissioning workflow, ESXi will keep trying to talk to a ghost device, leading to host instability and long boot times.

Follow this definitive checklist and procedure to ensure your environment stays clean and APD-free.

The “Safe-to-Remove” Checklist

Before you even touch the unmount button, verify these 7 critical points:

  1. Evacuate Data: Move or unregister all VMs, snapshots, templates, and ISO images from the datastore.
  2. HA Heartbeats: Ensure the datastore is NOT being used for vSphere HA heartbeats.
  3. No Clusters: Remove the datastore from any Datastore Clusters or Storage DRS management.
  4. Coredump: Confirm the LUN isn’t configured as a diagnostic coredump partition.
  5. SIOC: Disable Storage I/O Control (SIOC) for the datastore.
  6. RDMs: If the LUN is an Raw Device Mapping, remove the RDM from the VM settings (select “Delete from disk” to kill the mapping file).
  7. Scratch Location: Ensure the host isn’t using this LUN for its persistent scratch partition.

Pro Tip: Check Scratch Location via PowerCLI

Use this script to verify your scratch config across a cluster:

PowerShell
$cluster = "YourClusterName"
foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
    Get-VMHostAdvancedConfiguration -VMHost $esx -Name "ScratchConfig.ConfiguredScratchLocation"
}

Step 1: Identify your NAA ID

You need the unique Network Address Authority (NAA) ID to ensure you are pulling the right plug.

  • Via GUI: Check the Properties window of the datastore.
  • Via CLI: Run esxcli storage vmfs extent list

Step 2: The Unmount & Detach Workflow

1. Unmount the File System

In the Configuration tab > Storage, right-click the datastore and select Unmount. If you are doing this for multiple hosts, use the Datastores view (Ctrl+Shift+D) to unmount from the entire cluster at once.

2. Detach the Device (The Most Important Step)

Unmounting removes the “logical” access, but Detaching tells the kernel to stop looking for the “physical” device.

  • Switch to the Devices view.
  • Right-click the NAA ID and select Detach.
  • The state should now show as Unmounted.

Note: Detaching is a per-host operation. You must perform this on every host that has visibility to the LUN to avoid APD states.

Step 3: Cleanup the SAN & Host

Once the state is “Unmounted” across all hosts, you can safely unmap/unpresent the LUN from your SAN array.

Permanent Decommissioning

To prevent “ghost” entries from appearing in your detached list, run these commands on the host:

  1. List detached devices: esxcli storage core device detached list
  2. Remove the configuration permanently: esxcli storage core device detached remove -d <NAA_ID>

This entry was posted in VMware and tagged , , , , , , , , , , .

How to Change the Default Snapshot Location in VMware ESXi 5

Posted on Updated on

By default, VMware ESXi stores virtual machine snapshots in the same directory as the parent VM. If your primary datastore is running low on space, taking a new snapshot can fail or, worse, cause the VM to hang.

snapshot

Fortunately, you can redirect these snapshots (and swap files) to a different datastore with more “breathing room.”

Phase 1: vSphere Client Configuration

Before modifying files, we need to tell the VM not to store redo logs with the parent.

  1. Power OFF the Virtual Machine (This is mandatory for the changes to take effect).
  2. Right-click the VM and select Edit Settings.
  3. Go to the Options tab > General > Configuration Parameters.
  4. Click Add Row and enter:
    • Name: snapshot.redoNotWithParent
    • Value: true
  5. Click OK to save and exit.

Phase 2: CLI Configuration (.vmx Modification)

Now we define exactly where those snapshots should go.

  1. Log into the ESXi host via SSH or the local console.
  2. Navigate to your VM’s home directory:Bashcd /vmfs/volumes/[DatastoreName]/[VMName]
  3. Open the .vmx configuration file using the vi editor:Bashvi VMName.vmx
  4. Add the following line to the file, specifying your secondary datastore path:PlaintextworkingDir = "/vmfs/volumes/Secondary-Datastore/snapshots" (Press i to insert text, then Esc followed by :wq to save and exit.)

Phase 3: Reloading the VM

Changes to the .vmx file aren’t picked up until the VM is reloaded in the inventory.

  1. Find your VM’s ID:Bashvim-cmd vmsvc/getallvms | grep [VMName]
  2. Note the ID number (e.g., 13) and run the reload command:Bashvim-cmd vmsvc/reload 13

💡 Pro Tip: Keeping Swap Files in the Original Directory

By default, the workingDir parameter also moves the VM’s .vswp (Swap) file. If you only want to move the snapshots and keep the swap file with the parent VM for performance reasons, add this extra parameter in the Configuration Parameters (Phase 1):

Name: sched.swap.dir

Value: "/vmfs/volumes/Original-Datastore/VM-Directory"

#VMware #ESXi #StorageAdmin #SysAdmin #Virtualization #vSphere #TechTutorial #LazyAdmin #DataCenter #CloudComputing

This entry was posted in VMware and tagged , , , , , , , , .

How to change the thick or thin provisioning of a virtual disk

Posted on Updated on

🟢 Converting Thin to Thick (Inflation)

If your datastore has plenty of space and you need to eliminate the performance “write penalty” of a thin disk, you can Inflate it.

  1. Preparation: Power off the VM. Ensure there are no snapshots attached to the VM, as inflation only works on the base .vmdk.
  2. Locate the File: Go to the VM’s Summary tab. Under Resources, right-click the datastore and select Browse Datastore.
  3. The “Inflate” Action: Open the VM folder and find the .vmdk file. Right-click it and select Inflate.
    • Note: If “Inflate” is greyed out, the VM is likely still powered on or is already thick-provisioned.
  4. Finalize: Once the task finishes, you may need to Reload the .vmx file to ensure the vSphere UI reflects the new “Thick” status.

🔵 Converting Thick to Thin (Migration)

Converting back to Thin provisioning is slightly more complex because you cannot “deflate” a disk in place. You must move the data to a new location to reclaim the space.

Method A: Migration (Requires two Datastores)

This is the cleanest way to convert a disk using Storage vMotion or an offline migration.

  1. Power Off the VM (required for standard Migration; not required for Storage vMotion if licensed).
  2. Migrate: Right-click the VM and select Migrate > Change Datastore.
  3. Select Format: In the migration wizard, look for the Select Virtual Disk Format dropdown and choose Thin Provision.
  4. Target: Select a different datastore than the current one. vSphere will copy the blocks, only writing the actual data to the destination, effectively “thinning” the disk.

Method B: Cloning (Single Datastore)

If you only have one datastore, you cannot migrate the VM to itself to change the format.

  1. Right-click the VM and select Clone.
  2. During the clone wizard, select your current datastore as the destination.
  3. In the Disk Format section, select Thin Provision.
  4. Once complete, delete the old “Thick” VM and keep the new “Thin” one.

⚠️ Important Considerations

  • Backups: Always have a fresh backup. Moving or inflating disks is a heavy I/O operation.
  • Lazy vs. Eager Zeroed: When inflating to Thick, vSphere usually defaults to “Lazy Zeroed” (space is reserved, but blocks aren’t cleared until written to). For maximum performance (e.g., for Database logs or VSAN), “Eager Zeroed” is preferred.
  • Space Check: Before converting from Thin to Thick, ensure your datastore can handle the immediate consumption of the entire disk size.

#VMware #vSphere #Storage #ThinProvisioning #ThickProvisioning #SysAdmin #ITPro #Virtualization #LazyAdmin #CloudStorage #TechTips

This entry was posted in VMware and tagged , , , , , , , , .