VMware
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
Syslog Server storage logs size calculation

Upgrading your syslog retention is a great move for troubleshooting depth, but as your math shows, it comes with a significant increase in storage demands. Moving from 4GB to 40GB is a 10x jump, so ensuring your volume can handle the growth is critical.
Here is the breakdown of the calculation and the step-by-step guide to applying these changes.
📊 Syslog Storage Planning
Before modifying configuration files, verify your available disk space. Using your specific requirements for 100 hosts:
| Variable | Current Setting | Desired Setting |
| Max Log Size | 2 MB | 10 MB |
| Rotation Count | 20 Files | 40 Files |
| Retention per Host | 40 MB | 400 MB |
| Total Storage (100 Hosts) | 4,000 MB (4GB) | 40,000 MB (40GB) |
⚠️ A Note on Scalability
While you are planning for 100 hosts, keep in mind that the VMware Syslog Collector for Windows is officially supported for up to 30 hosts.
- The Risk: Beyond 30 hosts, the service may stop responding or drop logs without an error message.
- The Fix: If you need to support 100 hosts reliably, consider deploying multiple collectors or moving to a high-scale solution like VMware vRealize Log Insight.
🛠️ How to Modify Syslog Collector Configuration
To apply your new 10MB / 40 Rotate policy, you must manually edit the configuration XML.
1. Locate and Backup
Before editing, create a copy of the configuration file.
- vCenter 6.0:
%PROGRAMDATA%\VMware\vCenterServer\cfg\vmsyslogcollector\config.xml - vCenter 5.5 & older:
%PROGRAMDATA%\VMware\VMware Syslog Collector\vmconfig-syslog.xml
2. Edit the XML
Open the copy in a text editor (like Notepad++) and locate the <defaultValues> section. Update the values as follows:
<defaultValues> <port>514</port> <protocol>TCP,UDP</protocol> <maxSize>10</maxSize> <rotate>40</rotate> <sslPort>1514</sslPort></defaultValues>
3. Swap and Restart
- Stop the Service: Open
services.mscand stop the VMware Syslog Collector. - Replace File: Delete the original
config.xmland rename your modified copy to the original filename. - Start the Service: Restart the VMware Syslog Collector.
Lazy Admin Tip: If the logs don’t start flowing immediately, you may need to restart the syslog service on the ESXi hosts themselves to re-establish the connection to the server.
#VMware #vSphere #Syslog #DataCenter #Storage #SysAdmin #ITPro #Virtualization #LogManagement #LazyAdmin #TechGuide
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
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
ESXi Multipathing Decoded: MRU, Fixed, and Round Robin

When you present a LUN to an ESXi host, the Native Multipathing (NMP) engine automatically assigns a policy based on the type of storage array detected. However, as an admin, you need to understand why a policy was chosen—and when you should manually intervene.
1. Most Recently Used (MRU)
Best For: Active/Passive Arrays. MRU selects the first working path it finds at boot. If that path fails, it switches to a standby path.
- Key Behavior: It does not fail back. Even if the original path becomes healthy again, the host stays on the current path. This prevents “path thrashing” on Active/Passive arrays where switching controllers is an expensive operation.
2. Fixed
Best For: Active/Active Arrays. The Fixed policy uses a specific “Preferred Path.” If the preferred path fails, it moves to an alternative.
- Key Behavior: It does fail back. As soon as that designated preferred path is back online, the host immediately switches back to it.
3. Round Robin (RR)
Best For: Load Balancing (Active/Active or ALUA). Round Robin rotates through all available paths to distribute the I/O load.
- Active/Active: Uses every available path.
- Active/Passive: Only uses all paths leading to the active controller.
Note: For Microsoft Failover Clusters (MSCS), Round Robin is only supported on ESXi 5.5 and later.
4. Fixed with Array Preference (FIXED_AP)
Introduced in ESXi 4.1 for ALUA-capable arrays, this policy lets the storage array tell the host which path is the “optimal” one.
- Note: This was removed in ESXi 5.0 in favor of letting the NMP automatically select MRU or Fixed based on the array’s ALUA response.
⚠️ Critical Warnings for Admins
- Don’t Fight the NMP: VMware generally warns against manually changing a LUN from Fixed to MRU. The host chooses the policy based on the hardware it detects; forcing a change can lead to instability.
- Verify Vendor Support: Round Robin is powerful but not supported by every array. Always check the VMware Compatibility Guide before making it your default.
- MSCS Limitations: If you are virtualizing SQL clusters or other failover clusters, double-check your ESXi version before toggling Round Robin, or you risk losing disk heartbeat connectivity.
#VMware #ESXi #StorageAdmin #vSphere #Multipathing #SysAdmin #ITPro #Virtualization #LazyAdmin #DataCenter #StorageTips
Troubleshooting Storage Latency with esxtop: The Admin’s Guide

When “the server is slow,” the storage subsystem is usually the first suspect. While vCenter performance charts are great for history, esxtop gives you real-time data from the heart of the hypervisor.
🛠️ How to Configure esxtop for Storage Monitoring
You can monitor performance at three different levels depending on where you suspect the issue lies.
1. Per-HBA (Host Bus Adapter) Mode
- Command: Type
esxtop, then press d. - Tip: Press Shift + L and enter
36to see the full device names. - Fields: Press f and ensure b, c, d, e, h, and j are selected.
2. Per-LUN (Device) Mode
- Command: Type
esxtop, then press u. - Why use this? To see if a specific volume on your SAN is being hammered.
3. Per-VM (Virtual Machine) Mode
- Command: Type
esxtop, then press v. - Why use this? To identify the “noisy neighbor”—the specific VM that is consuming all the IOPS.
🔍 Analyzing the “Big Three” Latency Columns
To understand storage health, you must look at these three columns. They tell you exactly where the delay is happening.
| Column | Name | What it represents | Threshold |
| DAVG | Device Latency | Time spent at the hardware level (HBA + SAN). | < 10ms |
| KAVG | Kernel Latency | Time spent inside the VMware VMkernel. | < 1ms |
| GAVG | Guest Latency | Total latency perceived by the Guest OS (DAVG + KAVG). | < 10ms |
What the numbers are telling you:
- High DAVG: The problem is external to ESXi. Check your SAN controllers, disk spindles, or fabric switches.
- High KAVG: The problem is inside the host. This usually means the host is overloaded or there is a queueing issue (e.g., Disk.SchedNumReqOutstanding is too low).
- High GAVG: Your users are feeling the pain. If this exceeds 10–15ms consistently, application performance will suffer.
⚠️ When to Panic: Timeouts and Logs
If latency hits 5000ms (5 seconds), ESXi will abort the command. If you see high numbers in esxtop, immediately check your logs for SCSI aborts:
- ESXi 5.x/6.x/7.x/8.x:
/var/log/vmkernel.log - Legacy ESX 3.5/4.x:
/var/log/vmkernel
#VMware #ESXi #esxtop #StorageAdmin #SysAdmin #Virtualization #PerformanceMonitoring #ITPro #LazyAdmin #DataCenter #vSphere
Fixed: The VMRC Console has Disconnected (Error 2050470)

It’s a frustrating scenario: you go to check a virtual machine, and instead of a login screen, you get a black box with the message: “The VMRC Console has Disconnected… Trying to reconnect.” To make matters worse, the VM often appears unreachable on the network, leading you to believe the Guest OS has blue-screened or frozen. However, the issue is frequently just a hang-up in the VMware Remote Console (VMRC) process on your local management workstation.
The Quick Fix
You do not need to restart the VM or the ESXi host. Usually, the “stuck” process is living right on your own PC.
- Open Task Manager: Right-click your taskbar and select Task Manager (or press
Ctrl + Shift + Esc). - Find the Process: Go to the Processes or Details tab.
- Kill VMRC: Look for
vmware-vmrc.exe(orvmware-vmrc.exe*32on older systems). - End Task: Right-click the process and select End Task.
- Relaunch: Go back to your vSphere Client and attempt to open the console again.
Why does this happen?
This error usually occurs when the VMRC process loses its handshake with the ESXi host but fails to terminate properly. By killing the process, you force a fresh authentication and network handshake, which typically restores the video feed immediately.
What if the VM is still “Black Screened”?
If killing the local process doesn’t work and the VM is still unreachable via ping/RDP, the issue might be on the host side:
- Check the Hostd Service: Sometimes the management agent on the ESXi host needs a restart.
- Video Memory: Ensure the VM has enough Video RAM allocated in its “Edit Settings” menu to support the resolution you are using.
#VMware #vSphere #VMRC #SysAdmin #ITPro #Virtualization #TechSupport #LazyAdmin #ServerAdmin #WindowsTroubleshooting
- ← Previous
- 1
- 2
- 3