IT Operations

Nuclear Option: How to Force Power Off a Hung VM via SSH | Lazy Admin Blog

Posted on July 3, 2015 Updated on March 23, 2026

We’ve all been there: a Windows Update goes sideways or a database lock freezes a guest OS, and suddenly the “Shut Down Guest” command is greyed out or simply times out. When the GUI fails you, the ESXi Command Line (esxcli) is your best friend.

Step 1: Identify the “World ID”

In ESXi terminology, every running process is assigned a World ID. To kill a VM, you first need to find this unique identifier.

SSH into your ESXi host using Putty.
Run the following command to see all active VM processes:Bashesxcli vm process list
Locate your hung VM in the list. Look for the World ID (a long string of numbers). You will also see the Display Name and the path to the .vmx file to confirm you have the right one.

Step 2: Execute the Kill Command

ESXi offers three levels of “force” to stop a process. It is best practice to try them in order:

Soft: The most graceful. It attempts to give the guest OS a chance to shut down cleanly.
Hard: Equivalent to pulling the power cable. Immediate cessation of the VMX process.
Force: The “last resort.” Use this only if ‘Hard’ fails to clear the process from the kernel.

The Syntax:

Bash

esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber

Example (Hard Kill): esxcli vm process kill -t hard -w 5241852

Step 3: Verify the Result

After running the kill command, it may take a few seconds for the host to clean up the memory registration. Run the list command again to ensure it’s gone:

Bash

esxcli vm process list | grep "Your_VM_Name"

If the command returns nothing, the VM is officially offline, and you can attempt to power it back on via the vSphere Client.

Lazy Admin Tip 💡

If esxcli still won’t kill the VM, the process might be stuck in an “I/O Wait” state (usually due to a failed storage path). In that rare case, you might actually need to restart the Management Agents (services.sh restart) or, in extreme cases, reboot the entire host.

#VMware #vSphere #ESXi #SysAdmin #Troubleshooting #Virtualization #ITOps #LazyAdmin #ServerManagement #DataCenter

This entry was posted in VMware and tagged Data Center, esxcli, ESXi, IT Operations, Putty, SSH, SysAdmin Tips, Troubleshooting, Virtual Machine, VMware.

The Ultimate Robocopy Command for Large-Scale Migrations | Lazy Admin Blog

Posted on June 16, 2015 Updated on March 23, 2026

If you need to move huge files while keeping a close eye on progress, this is the syntax you want. It includes logging, multi-threading for speed, and the ability to resume if the network drops.

The “Power User” Command

DOS

			
robocopy "D:\Source_Data" "E:\Destination_Data" /s /e /z /mt:32 /tee /log+:"C:\Logs\MigrationLog.txt"

Switch Breakdown: Why We Use Them

Switch	What it does
/s /e	Copies all subdirectories, including empty ones.
/z	Restart Mode: If the connection drops mid-file, Robocopy can resume from where it left off instead of starting the file over. Essential for 100GB+ files!
/mt:32	Multi-Threading: Uses 32 threads to copy multiple files simultaneously. (Default is 8). Adjust based on your CPU/Disk speed.
/tee	Writes the status to the console window and the log file at the same time.
/log+:	Creates a log file. Using the `+` appends to an existing log rather than overwriting it—perfect for multi-day migrations.

How to Monitor Progress in Real-Time

Because we used the /tee and /log+ switches, you have two ways to monitor the status:

The Console: You’ll see a rolling percentage for each file directly in your Command Prompt.
Tail the Log: Since the log is being updated live, you can “tail” it from another window (or even remotely) to see the progress without touching the active copy session.

Lazy Admin Tip (PowerShell):

Open a PowerShell window and run this command to watch your Robocopy log update in real-time as files move:

Get-Content "C:\Logs\MigrationLog.txt" -Wait

Important Notes for Huge Files

Disk Quotas: Robocopy doesn’t check destination space before starting. Use dir or df (if using Linux targets) to ensure you have enough room.
Permissions: If you need to copy NTFS permissions (ACLs), add the /copyall switch.
Bandwidth: Running /mt:128 (the max) can saturate a 1Gbps link. If you’re copying over a live production network, stick to /mt:8 or /mt:16.

#WindowsServer #Robocopy #DataMigration #SysAdmin #ITInfrastructure #StorageAdmin #TechTips #LazyAdmin #CloudMigration

This entry was posted in Windows and tagged Data Center, File Transfer, IT Operations, Migration, Networking, PowerShell, Robocopy, Storage, SysAdmin Tools, Windows.

The Permission Panic: How to Backup and Restore Share & NTFS Permissions | Lazy Admin Blog

Posted on June 15, 2015 Updated on March 23, 2026

It only takes one “Inheritance” checkbox error to bring a department to a standstill. If you are migrating a file server or just performing routine maintenance, having a permission backup is your “Undo” button.

1. Share Permissions (The Registry Method)

“Share” permissions (the ones you see in the Sharing tab) are not stored on the files themselves; they are stored in the Windows Registry.

To Backup: Open a Command Prompt (Admin) and run:

DOS

			
reg export HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares shareperms.reg

To Restore: Simply import the file back on the new or repaired server:

DOS

reg import shareperms.reg

Note: You must restart the ‘Server’ service or reboot for the shares to reappear.

2. NTFS Permissions (The icacls Method)

NTFS permissions (the “Security” tab) are much more complex. We use the built-in icacls tool to handle these.

The Backup Command:

DOS

icacls d:\data /save ntfsperms.txt /t /c

/t: Recurses through all subfolders.
/c: Continues even if it hits a single file error (like a long file path).

The “Tricky” Restore Command: When restoring, icacls treats the paths inside the text file as relative. If your backup file says “Data\Folder1,” and you try to restore to D:\Data, it will look for D:\Data\Data\Folder1.

The Correct Syntax:

DOS