vSphere
How to Change the Default Snapshot Location in VMware ESXi 5

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.
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.
- Power OFF the Virtual Machine (This is mandatory for the changes to take effect).
- Right-click the VM and select Edit Settings.
- Go to the Options tab > General > Configuration Parameters.
- Click Add Row and enter:
- Name:
snapshot.redoNotWithParent - Value:
true
- Name:
- Click OK to save and exit.
Phase 2: CLI Configuration (.vmx Modification)
Now we define exactly where those snapshots should go.
- Log into the ESXi host via SSH or the local console.
- Navigate to your VM’s home directory:Bash
cd /vmfs/volumes/[DatastoreName]/[VMName] - Open the
.vmxconfiguration file using thevieditor:Bashvi VMName.vmx - Add the following line to the file, specifying your secondary datastore path:Plaintext
workingDir = "/vmfs/volumes/Secondary-Datastore/snapshots"(Pressito insert text, thenEscfollowed by:wqto 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.
- Find your VM’s ID:Bash
vim-cmd vmsvc/getallvms | grep [VMName] - 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
How to change the thick or thin provisioning of a virtual disk

🟢 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.
- Preparation: Power off the VM. Ensure there are no snapshots attached to the VM, as inflation only works on the base
.vmdk. - Locate the File: Go to the VM’s Summary tab. Under Resources, right-click the datastore and select Browse Datastore.
- The “Inflate” Action: Open the VM folder and find the
.vmdkfile. Right-click it and select Inflate.- Note: If “Inflate” is greyed out, the VM is likely still powered on or is already thick-provisioned.
- 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.
- Power Off the VM (required for standard Migration; not required for Storage vMotion if licensed).
- Migrate: Right-click the VM and select Migrate > Change Datastore.
- Select Format: In the migration wizard, look for the Select Virtual Disk Format dropdown and choose Thin Provision.
- 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.
- Right-click the VM and select Clone.
- During the clone wizard, select your current datastore as the destination.
- In the Disk Format section, select Thin Provision.
- 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
How to Restart Management Agents on an ESXi Host?

When an ESXi host appears as “Not Responding” in vCenter, or the Web Client becomes sluggish, you don’t always need to reboot the entire server. Often, simply restarting the Management Agents (hostd and vpxa) will restore connectivity without interrupting your running Virtual Machines.
Method 1: Using the Direct Console User Interface (DCUI)
If you have physical access to the server or a remote management console (like iDRAC, ILO, or IPMI), this is the safest method.
- Connect to your ESXi host console and press F2 to customize the system.
- Log in as root.
- Navigate to Troubleshooting Options using the arrow keys.
- Select Restart Management Agents.
- Press Enter, then press F11 to confirm the restart.
- Once finished, press Esc to log out.
Method 2: Using SSH or Local Shell
If SSH is enabled, you can restart the specific agents individually. This is the preferred “Lazy Admin” method as it provides granular control.
For ESXi 5.x, 6.x, and 7.x/8.x: Run these two commands to restart the host agent and the vCenter agent:
Bash
/etc/init.d/hostd restart/etc/init.d/vpxa restart
For legacy ESXi 4.x:
Bash
/etc/init.d/hostd restartservice vmware-vpxa restart
Method 3: The “Nuclear” Option (services.sh)
If the individual agent restarts don’t work, you can restart all management services on the host.
Command:
Bash
services.sh restart
⚠️ CRITICAL CAUTION
If LACP is enabled on your Distributed Virtual Switch (DVS), do not use
services.sh restart. Doing so can disrupt network connectivity. Instead, restart independent services or schedule a maintenance window.
Method 4: Resetting the Management Network
Sometimes the issue isn’t the agent, but the VMkernel interface itself. You can bounce the management interface (usually vmk0) with this one-liner:
Bash
esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0
The semicolon ensures the interface comes back up immediately after being disabled.
#VMware #ESXi #vSphere #SysAdmin #ITPro #Virtualization #Troubleshooting #LazyAdmin #DataCenter #TechTips #CloudAdmin
- ← Previous
- 1
- 2
