SysAdmin Basics
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 Fix: Keyboard or Mouse Not Working in a VMware Virtual Machine

It’s a frustrating classic: you click into your VM, and… nothing. The cursor doesn’t move, or the keyboard acts like it’s unplugged. Usually, this is a “focus” or driver issue rather than a hardware failure.
Here is the “Lazy Admin” checklist to get your inputs back online.
1. The “Focus” Check (The Most Common Culprit)
Virtualization software intercepts your hardware inputs. If the VM window doesn’t have “Focus,” your typing is still going to your host OS.
- Action: Click anywhere inside the VM console window.
- Pro Tip: Look at the bottom status bar of your VMware window. If the mouse icon isn’t lit up, the VM isn’t “grabbing” the input.
2. The Wireless Device “Passthrough” Trap
If you are using a wireless USB mouse/keyboard, the VM might have accidentally “claimed” the USB receiver for itself, cutting it off from the host.
- Action: Go to VM > Removable Devices and ensure your HID (Human Interface Device) is Disconnected from the VM so the host can manage it and pass the input through the software layer instead.
- Alternative: Remove the USB Controller from the VM settings and re-add it to reset the bus.
3. Driver Conflicts & Optimization
Sometimes, fancy “Gaming” drivers (Logitech G-Hub, Razer Synapse) inside the guest OS conflict with the VMware virtual driver.
- Action: Uninstall any non-standard mouse/keyboard software inside the VM.
- Optimization: In VMware Workstation settings, go to Preferences > Input and set “Optimize mouse for games” to Always or Automatic.
4. The Nuclear Option: Reinstall VMware Tools
The VMware Tools package includes the specialized vmmouse driver that handles smooth cursor movement and keyboard mapping. If this is corrupted, your input will fail.
- Action: 1. Press
Ctrl + Altto release your mouse to the host. 2. Go to VM > Install (or Reinstall) VMware Tools. 3. Use the keyboard (Tab and Spacebar) if the mouse isn’t working to navigate the installer.
5. Troubleshooting the Host (OS-Specific)
If the issue persists, the problem might be a service on your physical computer blocking the input stream.
- Windows Hosts: Run
msconfigto perform a “Clean Boot,” disabling non-Microsoft services to see if a background app is interfering. - Linux Hosts: Drop to Run Level 2 to disable start daemons and test the raw input.
#VMware #Virtualization #SysAdmin #ITSupport #TechTips #LazyAdmin #VMwareWorkstation #vSphere #WindowsTips #LinuxTips
How to get Serial number and System information of ESXi host remotely using putty

🛠️ Method 1: Using esxcfg-info
The esxcfg-info command is a comprehensive tool that dumps a massive amount of data regarding the host’s configuration. Filtering this with grep is the quickest way to find your serial number.
Command:
Bash
esxcfg-info | grep "Serial Number"
- What it does: Searches the entire configuration dump for the specific “Serial Number” string.
- LazyAdmin Tip: If you get too many results, try
esxcfg-info -w | grep "Serial Number"to focus specifically on hardware information.
🛠️ Method 2: Using dmidecode (DMI Table Decoder)
If you need more than just the serial number—such as the Manufacturer, Product Name (Model), and UUID—dmidecode is the standard tool. It retrieves data directly from the system’s Desktop Management Interface (DMI) table.
Command:
Bash
/usr/sbin/dmidecode | grep -A4 "System Information"
- What it does: The
-A4flag tells grep to show the 4 lines after the match. - The Result: You will typically see:
- Manufacturer (e.g., Dell Inc., HP, Cisco)
- Product Name (e.g., PowerEdge R740)
- Version
- Serial Number
- UUID
🛠️ Method 3: The Modern ESXCLI Way
If you are on ESXi 6.x or 7.x/8.x, VMware has standardized most commands under the esxcli framework. This is often faster and cleaner than the legacy scripts.
Command:
Bash
esxcli hardware platform get
- Why use this? It provides a clean, organized output of the Vendor Name, Product Name, and Serial Number without needing to
grep.
⚠️ Troubleshooting Access
- SSH is Disabled: By default, SSH is turned off for security. You must enable it via the DCUI (the yellow and grey monitor screen) under “Troubleshooting Options” or via the Host Client web interface.
- Permission Denied: Ensure you are logging in as
root. Standard users generally do not have permission to query the hardware DMI tables. - Shell Lockdown: If the host is in “Lockdown Mode,” you will be unable to SSH in even with the correct credentials. You’ll need to disable Lockdown Mode via vCenter first.
#VMware #ESXi #SysAdmin #ITPro #CommandLine #ServerHardware #TechTips #LazyAdmin #DataCenter #RemoteManagement #vSphere
🏗️ The Architecture: How UCS Manager “Thinks”

For B-Series (blade) and integrated C-Series (rack) servers, monitoring is driven by a “Queen Bee and Worker Bee” relationship.
1. Data Management Engine (DME)
The DME is the brain of the system. It maintains the UCS XML database, which stores the current inventory, health, and configuration of every physical and logical component in your domain.
- Real-Time Only: By default, the DME only shows active faults. It does not store a historical log of everything that ever went wrong.
2. Application Gateway (AG)
The AGs are the “worker bees.” They communicate directly with endpoints (servers, chassis, I/O modules) to report status back to the DME.
- Server Monitoring: AGs monitor health via the CIMC (Cisco Integrated Management Controller) using IPMI and SEL logs.
3. Northbound Interfaces
These are the “outputs” that you, the administrator, actually interact with:
- SNMP & Syslog: Read-only interfaces used for external monitoring tools.
- XML API: A powerful “read-write” interface used for both monitoring and changing configurations.
🚨 Understanding Faults and Their Lifecycle
In Cisco UCS, a fault is a “stateful” object. It doesn’t just appear and disappear; it transitions through a specific lifecycle to prevent “alert fatigue” caused by temporary glitches.
The Fault Lifecycle
- Active: The condition occurs, and a fault is raised.
- Soaking: The condition clears quickly, but the system waits (the flap interval) to see if it comes back.
- Flapping: The fault is raised and cleared several times in rapid succession.
- Cleared: The issue is resolved, but the fault remains visible for a “retention interval” so you don’t miss it.
- Deleted: The fault is purged from the database.
✅ Best Practices for Monitoring
1. The “Severity” Rule
For UCS Manager, your monitoring tool should focus on faults with a severity of Critical or Major. Ignore “Info” or “Condition” alerts unless you are deep-diving into a specific issue.
2. Filter out “FSM” Faults
Finite State Machine (FSM) faults are usually transient. They often trigger during a task (like a BIOS POST during a service profile association) and resolve themselves on a second or third retry.
- Note: This only applies to UCS Manager. Standalone C-Series servers do not use FSM, so all their faults are usually relevant.
3. Use the XML API for C-Series
If you are managing standalone C-Series servers, the XML API is the gold standard. It supports Event Subscription, which pushes proactive alerts to you rather than making your tool “pull” data constantly.
📚 Essential Resource Links
Keep these bookmarked for when those cryptic SNMP OIDs start popping up in your logs:
#CiscoUCS #SysAdmin #DataCenter #Networking #Cisco #ITPro #ServerMonitoring #LazyAdmin #Virtualization #TechTutorials
How to Boot a Windows Server 2003 DC into Directory Services Restore Mode (DSRM)

There are times when Active Directory becomes unstable, or you need to perform a “System State” restore. To do this, you must take the Domain Controller offline by booting into Directory Services Restore Mode (DSRM).
In this mode, the server stops functioning as a DC and instead functions as a standalone member server, allowing you to manipulate the AD database files (ntds.dit) while they aren’t in use.
⚠️ The Golden Rule of DSRM: The Password
When you boot into DSRM, Active Directory is not running. This means you cannot log in with your Domain Admin credentials.
You must use the Local Administrator account, and the password is the unique DSRM Password that was set years ago when the server was first promoted to a Domain Controller (via dcpromo).
Tip: If you’ve forgotten this password but the server is still currently running as a DC, you can reset it before rebooting using the
setdsrmpasswordcommand inntdsutil.
Step-by-Step: Booting into DSRM Locally
If you have physical access (or console access via iDRAC/iLO/vCenter) to the machine, follow these steps:
- Initiate a Restart: Restart the Domain Controller as you normally would.
- The F8 Menu: As soon as the BIOS screen disappears and the Operating System selection menu appears, start tapping the F8 key.
- Advanced Options: You will be presented with the Windows Advanced Options Menu. Use the arrow keys to select Directory Services Restore Mode (Windows domain controllers only) and press Enter.
- Login: Once the Windows login screen appears, log on as the Local Administrator using that specific DSRM password.
What happens in this mode?
- The
NTDSservice is stopped. - The server does not respond to authentication requests from users.
- The local SAM (Security Accounts Manager) database handles authentication.
- You can now run
ntdsutilor backup software to perform database maintenance or restores.
#ActiveDirectory #DSRM #SysAdmin #WindowsServer #ITPro #TechSupport #ServerAdmin #LazyAdmin #Troubleshooting #LegacyIT
