Sunday, August 26, 2012
Friday, July 13, 2012
Daily Health Reports for vCenter by Alan (http://www.virtu-al.net)
Have you ever thought.. get "Granular Report" of your VC - Full view of VC on HTML report!!
You should visit below..
http://www.virtu-al.net/vcheck-pluginsheaders/vcheck/
Report contains below - Damn easy via Power CLI..
You should visit below..
http://www.virtu-al.net/vcheck-pluginsheaders/vcheck/
Report contains below - Damn easy via Power CLI..
- General Details
- Number of Hosts
- Number of VMs
- Number of Templates
- Number of Clusters
- Number of Datastores
- Number of Active VMs
- Number of Inactive VMs
- Number of DRS Migrations for the last days
- Snapshots over x Days old
- Datastores with less than x% free space
- VMs created over the last x days
- VMs removed over the last x days
- VMs with No Tools
- VMs with CD-Roms connected
- VMs with Floppy Drives Connected
- VMs with CPU ready over x%
- VMs with over x amount of vCPUs
- List of DRS Migrations
- Hosts in Maintenance Mode
- Hosts in disconnected state
- NTP Server check for a given NTP Name
- NTP Service check
- vmkernel warning messages ov the last x days
- VC Error Events over the last x days
- VC Windows Event Log Errors for the last x days with VMware in the details
- VC VMware Service details
- VMs stored on datastores attached to only one host
- VM active alerts
- Cluster Active Alerts
- If HA Cluster is set to use host datastore for swapfile, check the host has a swapfile location set
- Host active Alerts
- Dead SCSI Luns
- VMs with over x amount of vCPUs
- vSphere check: Slot Sizes
- vSphere check: Outdated VM Hardware (Less than V7)
- VMs in Inconsistent folders (the name of the folder is not the same as the name)
- VMs with high CPU usage
- Guest disk size check
- Host over committing memory check
- VM Swap and Ballooning
- ESXi hosts without Lockdown enabled
- ESXi hosts with unsupported mode enabled
- General Capacity information based on CPU/MEM usage of the VMs
- vSwitch free ports
- Disk over commit check
- Host configuration issues
- VCB Garbage (left snapshots)
- HA VM restarts and resets
- Inaccessible VMs
Virtual CD - becomes "Show Stopper" for Manual / DRS vMotion - How to solve
Virtual CD - becomes "Show Stopper" for Manual / DRS vMotion - How to solve
1) Tool Based Disconnect (As per docs - host wise)
2) Power CLI based Disconnect (By ESX, Cluster, Datacenter) - Single Shot
Method1 - Tool Based
There is a tool by "Eric Sloof" - This Tool Scans all Virtual
Machines and shows if they have a CD connected to it. After scanning the VM’s
you can disconnect all the CD’s with a click of a button.
vmCDConnected --> http://www.ntpro.nl/blog/archives/172-Software.html
Method2 - Script Based -I like this way - Power of Reach to ESX / Cluster / Data Center
Execute Script on one ESX Host & disconnect Virtual CD for All VM's on ESX
(Get-VM -Location ( Get-VMHost "ESX host name HERE")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }
Execute script on Whole cluster:
(Get-VM -Location ( Get-Cluster "Cluster Name HERE")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }
Why not by Datacenter:
(Get-VM -Location ( Get-Datacenter "Datacenter Name HERE")) | `
ForEach ( $_ ) { Get-CDDrive $_ | `
Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | `
Set-CDDrive -NoMedia -Confirm:$False }
Monday, June 11, 2012
ESX host Maintenance mode from ESX CLI
1) login to ESX host to execute below.
1) login to ESX host to execute below.
To enter Maintenance
Mode, at the ESX console:
vimsh
-n -e /hostsvc/maintenance_mode_enter
To exit Maintenance
Mode :
vimsh
-n -e /hostsvc/maintenance_mode_exit
To display whether
the ESX Server is currently in maintenance mode or not type:
vimsh
-n -e"hostsvc/hostsummary" | grep inMaintenanceMode
Using system libcrypto, version 90810F
inMaintenanceMode = false,
(False - means "not in maintenance mode" / True - Means "in maintenance mode")
Labels:
CLI,
Step-By-Step-Guide
Failed write command to write-quiesced partition
ESX box may see below errors, due to some storage box side issues.you may observe mostly on all the ESX hosts of the VC Cluster - kind of below errors.
ALERT: ScsiDeviceIO: 2352: Failed write command to write-quiesced partition naa.50a9800064656c5a4a5a654e35594123:1
Extract from /var/log/vmkernel - below
/var/log/vmkernel cpu21:4342)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x4102ff3ac040) to NMP device "naa.50a9800064656c5a4a5a654e35594123" failed on physical path "vmhba1:C0:T1:L1" H:0x8 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
/var/log/vmkernel cpu21:4342)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:
NMP device "naa.50a9800064656c5a4a5a654e35594123" state in doubt; requested fast path state update...
/var/log/vmkernel cpu21:4342)ScsiDeviceIO: 1672: Command 0x2a to
device "naa.50a9800064656c5a4a5a654e35594123" failed H:0x8 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
Solution
There may be nothing much on ESX side to resolve these errors, Involve your storage vendor to solve this - refer at below VMware KB for more details.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009482
How to identify your DATA STORE name from NAA ID - Example below
# esxcfg-scsidevs -m |
grep -i "naa.50a9800064656c5a4a5a654e35594123"
How to identify you LUN ID from Data Store Name
Select ESX at VC - configuration - storage - right click - Properties
Labels:
DataStore,
Logs,
SAN,
TrobuleShoot
Friday, June 8, 2012
Migration / vmotion - of vm fails at 82%
vmotion of vm fails by throwing error -> "Source detected that destination failed to resume"
Scenario 1 (APD - "All Paths Dead issue" on either Source / Target ESX)
APD may be generally caused by improper removal of RDM's
(without removing from VM - remove/unmask at Storage end)
1) grep -i apd /var/log/vmkernel (execute on Source & Target ESX)
2) If you find any APD entries (similar to below) - your "vmkernel/COS OS"
will busy in negotiating / trying to reheal the Dead paths and causing vMotion failures.
WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device "naa.6090a06830772d1a80b95495e700708b"
WARNING: vmw_psp_rr: psp_rrSelectPath: Could not select path for device "naa.6090a06830772d1a80b95495e700708b"
WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device "naa.6090a06830772d1a80b95495e700708b"
failed to issue command due to Not found (APD), try again...
Solution - # esxcfg-rescan vmhba1 && esxcfg-rescan vmhba2 (vmhbaX in your case)
Hope - This issue is resolved in ESX/ESXi 4.1 Update 1 & default with ESXi 5.0.
If no go; Unfortunately - only way to Resolve "APD issue" is restart ESX box
As the VM's does not migrate from the APD issue Host - you need downtime for all the VM's
Tip - Take diligent mesaures while removing LUN's from Storage end (remove from OS/VM properly)
More info - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016626
Scenario 2 (Incorrect h/w version of VM)
/var/log/vmware/hostd.log of "SOURCE ESX" contains below
ResolveCb: Failed with fault: (vmodl.fault.SystemError) {
reason = "Source detected that destination failed to resume."
msg = ""
}
/var/log/vmware/hostd.log of "TARGET ESX" contains below
Upgrade is required since hwVersion in config file is 3
Solution - right click on VM - upgrade virtual Hardware
Scenario 3 - UUID of NFS data store is different on source and target ESX hosts
# vdf -h (check on source and target ESX host)
if UUID is different (migration fails), generally UUID difference is caused by the way you add host to VC
you may add host by (ip / hostname / hostname.domain / FQDN)
To resolve UUID issues - follow below vmware KB..
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=1006052
vmotion of vm fails by throwing error -> "Source detected that destination failed to resume"
Scenario 1 (APD - "All Paths Dead issue" on either Source / Target ESX)
APD may be generally caused by improper removal of RDM's
(without removing from VM - remove/unmask at Storage end)
1) grep -i apd /var/log/vmkernel (execute on Source & Target ESX)
2) If you find any APD entries (similar to below) - your "vmkernel/COS OS"
will busy in negotiating / trying to reheal the Dead paths and causing vMotion failures.
WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device "naa.6090a06830772d1a80b95495e700708b"
WARNING: vmw_psp_rr: psp_rrSelectPath: Could not select path for device "naa.6090a06830772d1a80b95495e700708b"
WARNING: NMP: nmp_DeviceAttemptFailover: Retry world failover device "naa.6090a06830772d1a80b95495e700708b"
failed to issue command due to Not found (APD), try again...
Solution - # esxcfg-rescan vmhba1 && esxcfg-rescan vmhba2 (vmhbaX in your case)
Hope - This issue is resolved in ESX/ESXi 4.1 Update 1 & default with ESXi 5.0.
If no go; Unfortunately - only way to Resolve "APD issue" is restart ESX box
As the VM's does not migrate from the APD issue Host - you need downtime for all the VM's
Tip - Take diligent mesaures while removing LUN's from Storage end (remove from OS/VM properly)
More info - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016626
Scenario 2 (Incorrect h/w version of VM)
/var/log/vmware/hostd.log of "SOURCE ESX" contains below
ResolveCb: Failed with fault: (vmodl.fault.SystemError) {
reason = "Source detected that destination failed to resume."
msg = ""
}
/var/log/vmware/hostd.log of "TARGET ESX" contains below
Upgrade is required since hwVersion in config file is 3
Solution - right click on VM - upgrade virtual Hardware
Scenario 3 - UUID of NFS data store is different on source and target ESX hosts
# vdf -h (check on source and target ESX host)
if UUID is different (migration fails), generally UUID difference is caused by the way you add host to VC
you may add host by (ip / hostname / hostname.domain / FQDN)
To resolve UUID issues - follow below vmware KB..
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=1006052
Labels:
vMotion
Vmtools install
failed - on windows - internal error 2318.
Sometimes You may experience a vmtools / vmware-tools installation failed,
It prompts you to uninstall existing first to continue with vmtools upgrade,
and if you try to uninstall existing vmtools - it exits with various reasons
(may happen due to existing vmtools files / registry was corrupted)

Here is the trick for you to uninstall / clean the Registry.
1) Right click on Windows VM / guest at VC - Choose install / upgrade VMware tools
2) Select Manual installation
3) Goto RDP / console of VM - ensure you find virtual CD at MyComputer
4) Find drive letter for your Virtual CD (Ex : D:) -> Go to command prompt ->
D:\> setup.exe /c (if your OS is 32bit) or setup64.exe /c (if 64 bit OS)
5) Now you try to reinstall the VMware tools - it should proceed to install.
Labels:
VM Tools
Windows Guest
When it comes to mass deploy / large scale of VM's (vmware tools update) - it will be cumbersome for you to click on each VM and update VMware tools. Here is the way you can use "Silent install method" via SSH log on script / Power CLI.
To perform a silent, non GUI with suppressed reboot
VMware Tools installation in a Windows guest operating system:
Run
the command:
setup.exe /S /v /qn REBOOT=R
Note: The installer might indicate if a reboot is necessary by exiting
with ERROR_SUCCESS_REBOOT_REQUIRED.
Alternatively, in vCenter Server,
right-click on a virtual machine, click Install/Upgrade VMware Tools, and enter /S
/v /qn REBOOT=R the Advanced field.
Source - VMware KB --> 1018377
Labels:
VM Tools
Thursday, February 24, 2011
Troubleshooting Performance Related Problems in vSphere 4.1 Environments
Source : communities.vmware.com
The hugely popular Performance Troubleshooting for VMware vSphere 4 guide is now updated for vSphere 4.1 . This document provides step-by-step approach for troubleshooting most common performance problems in vSphere-based virtual environments. The steps discussed in the document use performance data and charts readily available in the vSphere Client and esxtop to aid the troubleshooting flows. Each performance troubleshooting flow has two parts:
- How to identify the problem using specific performance counters.
- Possible causes of the problem and solutions to solve it.
New sections that were added to the document include troubleshooting performance problems in resource pools on standalone hosts and DRS clusters, additional troubleshooting steps for environments experiencing memory pressure (hosts with compressed and swapped memory), high CPU ready time in hosts that are not CPU saturated, environments sharing resources such as storage and network, and environments using snapshots.
This document by no means covers the entire breadth of performance-related problems. We request the readers of this document, including VMware performance community members and vSphere administrators, to help us enhance this document by letting us know about all the performance problems they encounter in their vSphere-based virtual environments, including those that require elaborate troubleshooting steps. We hope that the community will actively contribute by engaging in live discussions, providing feedback, and asking questions. All this input will serve as the topics for future updates.
Labels:
Performance,
Step-By-Step-Guide,
TrobuleShoot
Monday, January 24, 2011
Due to a possible dead lock on rpmdb, upgrading ESX 4.0 to 4.0 Update 1 can fail or time out and leave the host in an unusable state
Due to a possible dead lock on rpmdb, upgrading ESX 4.0 to 4.0 Update 1 can fail or time out and leave the host in an unusable state
Symptoms
When attempting to upgrade ESX 4.0 to ESX 4.0 Update 1 (U1), you may experience these symptoms:
- Upgrade operation may fail or hang and can result in an incomplete installation
- Upon reboot, the host that was being upgraded may be left in an inconsistent state and may display a purple diagnostic screen with the following error:
COS Panic: Int3 @ mp_register_ioapic
Purpose
ESX 4.0 U1 includes an upgrade to glibc version 5.3 which implements a change in locking mechanism compared to glibc version 5.2 already installed with ESX 4.0. If rpm command is run during the installation of ESX 4.0 U1, a dead lock may be placed on rpmdb. For more information, see RedHat PR 463921.
As a result, upgrading ESX 4.0 to 4.0 U1 can fail or time out and leave the host in an unusable state.
While this issue is not hardware vendor specific, this has been reported to occur on HP Proliant systems if Insight Management Agents are already installed and running on the host being upgraded. Investigations into this issue revealed that Insight Management Agents run rpm commands on a regular basis which triggers the deadlock during the U1 installation. This can also occur on any system from other vendors that has a process or an application running rpm, or if you happen to manually run the rpm command, like rpm -qa, while Update 1 installation is in progress.
Note: VMware esxupdate tool can be used standalone and is also used by VMware Update Manager and VMware Host Update Utility.
Note: VMware esxupdate tool can be used standalone and is also used by VMware Update Manager and VMware Host Update Utility.
Resolution
Who is affected
- Customers using VMware vSphere 4 upgrading to ESX 4.0 U1 on HP Proliant systems with a supported version of HP Insight Management Agents running.
- Customers running rpm commands on systems from any vendor while upgrading to ESX 4.0 U1.
This affects any of the following upgrading scenarios:
- Upgrade using Update Manager
- Upgrade using esxupdate
- Upgrade using vSphere Host Update Utility
Note: ESXi is not affected.
Solution
ESX 4.0 Update 1 has been re-released with changes to avoid this issue. The installation process checks for running agents and stops them before proceeding.
The re-released ESX 4.0 Update1 is referred to as ESX 4.0 Update 1a and is available via vSphere Update Manager (VUM) and the VMware Downloads site.
Note: The changes in ESX 4.0 Update 1a do not address the issue with glibc locking mechanism. It is critical that you do not run rpm commands on any host while the ESX 4.0 Update 1a installation is in progress.
If you meet one or both of the conditions of Who is Affected and you already ran the original ESX 4.0 Update 1 installation but have not rebooted the host, do not reboot the ESX host. Contact VMware Technical Support for assistance. For more information, see How to Submit a Support Request.
WARNING: Rebooting the host means the host may need to be reinstalled because it is not recoverable after a reboot.
WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance before reinstalling.
Labels:
TrobuleShoot
Restarting hostd (mgmt-vmware) on ESX hosts restarts hosted virtual machines where virtual machine Startup/Shutdown is enabled
Details
This is an issue with virtual machines that are set to automatically start or stop and that are hosted on ESX 3.x. Manually shutting down, starting up, or restarting hostd through the service console causes hosted virtual machines that are set to automatically change power states to stop, start, or restart, respectively.
This is an issue with virtual machines that are set to automatically start or stop and that are hosted on ESX 3.x. Manually shutting down, starting up, or restarting hostd through the service console causes hosted virtual machines that are set to automatically change power states to stop, start, or restart, respectively.
Disable Virtual Machine Startup/Shutdown for the ESX host through VirtualCenter or a VMware Infrastructure (VI) Client that is directly connected to the host.
GUI Method
To disable Virtual Machine Startup/Shutdown:
- Log in to VirtualCenter.
- Select the ESX Server host where you want restart hostd.
- Select the Configuration tab.
- Select Virtual Machine Startup/Shutdown.
- Select Properties.
- Deselect Allow Virtual machines to start and stop automatically with the system.
CLI Method
If the host is not reachable through VirtualCenter or the VI Client:
- Log in to the ESX Server service console as root.
- At the command line run vimsh.
- At the [/] prompt, type:
hostsvc/autostartmanager/enable_autostart 0
- Type exit. You can now safely restart mgmt-vmware (hostd).
Labels:
TrobuleShoot
How to Divide & Combine vSphere 4.x license keys
Dividing vSphere 4.x license keys
To divide vSphere 4.x license keys:
- Go to http://www.vmware.com/account/login.do and log in to the license portal.
- Expand the product edition (e.g vSphere 4 Standard) under Your VMware Product License Keys to view the available license keys.
- Click Divide.
- Select the license you wish to Divide by clicking on the associated radio button.
- Click Continue.
You can review the order information for the license you wish to split and decide how many new licenses you want to generate.
- Enter the count for each of the new license keys.
- Click Continue.
On the confirmation page, you can review the split operation. A warning message appears.
- Click Confirm.
A dialog is displayed while the operation is in progress. When the Split Operation is complete, you return to the Licensing page. The original license key is no longer visible in the portal and you see the newly generated license keys indicated by New.
Combining vSphere 4.x license keys
To combine the vSphere 4.x license keys:
- Go to http://www.vmware.com/account/login.do and log in to the license portal.
- Expand the product edition (e.g vSphere 4 Standard) under Your VMware Product License Keys to view the available license keys.
Note: You cannot combine license keys that belong to different editions. For example you cannot combine a vSphere Standard License key with a vSphere Enterprise License Key.
- Click Combine.
- Select the licenses you wish to combine by clicking on the associated check boxes
- Click Continue.
On the confirmation page, you have a chance to review the combine operation. A warning message appears.
- Click Confirm to proceed with the combine operation.
A dialog is displayed while the operation is in progress. When the Combine Operation completes, you return to the Licensing page. The original license keys are no longer visible in the portal. You see the newly generated license keys indicated by New.
Friday, January 14, 2011
ESXTOP - Deep Dive
Source - www.yellow-bricks.com
Thresholds
Howto – Run
Howto – Capture
Howto – Analyze
Howto – Limit esxtop to specific VMs
References
Changelog
This page is solely dedicated to one of the best tools in the world for ESX; esxtop.
Intro
I am a huge fan of esxtop! I read a couple of pages of the esxtop bible every day before I go to bed. Something I however am always struggling with is the “thresholds” of specific metrics. I fully understand that it is not black/white, performance is the perception of a user in the end.There must be a certain threshold however. For instance it must be safe to say that when %RDY constantly exceeds the value of 20 it is very likely that the VM responds sluggish. I want to use this article to “define” these thresholds, but I need your help. There are many people reading these articles, together we must know at least a dozen metrics lets collect and document them with possible causes if known.
Please keep in mind that these should only be used as a guideline when doing performance troubleshooting! Also be aware that some metrics are not part of the default view. You can add fields to an esxtop view by clicking “f” on followed by the corresponding character.
I used VMworld presentations, VMware whitepapers, VMware documentation, VMTN Topics and of course my own experience as a source and these are the metrics and thresholds I came up with so far. Please comment and help build the main source for esxtop thresholds.
Metrics and Thresholds
| Display | Metric | Threshold | Explanation |
| CPU | %RDY | 10 | Overprovisioning of vCPUs, excessive usage of vSMP or a limit(check %MLMTD) has been set. See Jason’s explanation for vSMP VMs |
| CPU | %CSTP | 3 | Excessive usage of vSMP. Decrease amount of vCPUs for this particular VM. This should lead to increased scheduling opportunities. |
| CPU | %SYS | 20 | The percentage of time spent by system services on behalf of the world. Most likely caused by high IO VM. Check other metrics and VM for possible root cause |
| CPU | %MLMTD | 0 | The percentage of time the vCPU was ready to run but deliberately wasn’t scheduled because that would violate the “CPU limit” settings. If larger than 0 the world is being throttled due to the limit on CPU. |
| CPU | %SWPWT | 5 | VM waiting on swapped pages to be read from disk. Possible cause: Memory overcommitment. |
| MEM | MCTLSZ | 1 | If larger than 0 host is forcing VMs to inflate balloon driver to reclaim memory as host is overcommited. |
| MEM | SWCUR | 1 | If larger than 0 host has swapped memory pages in the past. Possible cause: Overcommitment. |
| MEM | SWR/s | 1 | If larger than 0 host is actively reading from swap(vswp). Possible cause: Excessive memory overcommitment. |
| MEM | SWW/s | 1 | If larger than 0 host is actively writing to swap(vswp). Possible cause: Excessive memory overcommitment. |
| MEM | CACHEUSD | 0 | If larger than 0 host has compressed memory. Possible cause: Memory overcommitment. |
| MEM | ZIP/s | 0 | If larger than 0 host is actively compressing memory. Possible cause: Memory overcommitment. |
| MEM | UNZIP/s | 0 | If larger than 0 host has accessing compressed memory. Possible cause: Previously host was overcommited on memory. |
| MEM | N%L | 80 | If less than 80 VM experiences poor NUMA locality. If a VM has a memory size greater than the amount of memory local to each processor, the ESX scheduler does not attempt to use NUMA optimizations for that VM and “remotely” uses memory via “interconnect”. |
| NETWORK | %DRPTX | 1 | Dropped packets transmitted, hardware overworked. Possible cause: very high network utilization |
| NETWORK | %DRPRX | 1 | Dropped packets received, hardware overworked. Possible cause: very high network utilization |
| DISK | GAVG | 25 | Look at “DAVG” and “KAVG” as the sum of both is GAVG. |
| DISK | DAVG | 25 | Disk latency most likely to be caused by array. |
| DISK | KAVG | 2 | Disk latency caused by the VMkernel, high KAVG usually means queuing. Check “QUED”. |
| DISK | QUED | 1 | Queue maxed out. Possibly queue depth set to low. Check with array vendor for optimal queue depth value. |
| DISK | ABRTS/s | 1 | Aborts issued by guest(VM) because storage is not responding. For Windows VMs this happens after 60 seconds by default. Can be caused for instance when paths failed or array is not accepting any IO for whatever reason. |
| DISK | RESETS/s | 1 | The number of commands reset per second. |
| DISK | CONS/s | 20 | SCSI Reservation Conflicts per second. If many SCSI Reservation Conflicts occur performance could be degraded due to the lock on the VMFS. |
Running esxtop
Although understanding all the metrics esxtop provides seem to be impossible using esxtop is fairly simple. When you get the hang of it you will notice yourself staring at the metrics/thresholds more often than ever. The following keys are the ones I use the most.Open console session or ssh to ESX(i) and type:
esxtopBy default the screen will be refreshed every 5 seconds, change this by typing:
s 2Changing views is easy type the following keys for the associated views:
c = cpu m = memory n = network i = interrupts d = disk adapter u = disk device (includes NFS as of 4.0 Update 2) v = disk VM p = power states V = only show virtual machine worlds e = Expand/Rollup CPU statistics, show details of all worlds associated with group (GID) k = kill world, for tech support purposes only! l = limit display to a single group (GID), enables you to focus on one VM # = limiting the number of entitites, for instance the top 5 2 = highlight a row, moving down 8 = highlight a row, moving up 4 = remove selected row from view e = statistics broken down per world 6 = statistics broken down per worldAdd/Remove fields:
fChanging the order:
oSaving all the settings you’ve changed:
WKeep in mind that when you don’t change the file-name it will be saved and used as default settings.
Help:
?In very large environments esxtop can high CPU utilization due to the amount of data that will need to be gathered and calculations that will need to be done. If CPU appears to highly utilized due to the amount of entities (VMs / LUNs etc) a command line option can be used which locks specific entities and keeps esxtop from gathering specific info to limit the amount of CPU power needed:
esxtop -lMore info about this command line option can be found here.
Capturing esxtop results
First things first. Make sure you only capture relevant info. Ditch the metrics you don’t need. In other words run esxtop and remove/add(f) the fields you don’t actually need or do need! When you are finished make sure to write(W) the configuration to disk. You can either write it to the default config file(esxtop4rc) or write the configuration to a new file.Now that you have configured esxtop as needed run it in batch mode and save the results to a .csv file:
esxtop -b -d 2 -n 100 > esxtopcapture.csvWhere “-b” stands for batch mode, “-d 2″ is a delay of 2 seconds and “-n 100″ are 100 iterations. In this specific case esxtop will log all metrics for 200 seconds. If you want to record all metrics make sure to add “-a” to your string.
Or what about directly zipping the output as well? These .csv can grow fast and by zipping it a lot of precious diskspace can be saved!
esxtop -b -a -d 2 -n 100 | gzip -9c > esxtopoutput.csv.gz
Analyzing results
You can use multiple tools to analyze the captured data.- perfmon
- excel
- esxplot
- Run: perfmon
- Right click on the graph and select “Properties”.
- Select the “Source” tab.
- Select the “Log files:” radio button from the “Data source” section.
- Click the “Add” button.
- Select the CSV file created by esxtop and click “OK”.
- Click the “Apply” button.
- Optionally: reduce the range of time over which the data will be displayed by using the sliders under the “Time Range” button.
- Select the “Data” tab.
- Remove all Counters.
- Click “Add” and select appropriate counters.
- Click “OK”.
- Click “OK”.
With MS Excel it is also possible to import the data as a CSV. Keep in mind though that the amount of captured data is insane so you might want to limit it by first importing it into perfmon and then select the correct timeframe and counters and export this to a CSV. When you have done so you can import the CSV as follows:
- Run: excel
- Click on “Data”
- Click “Import External Data” and click “Import Data”
- Select “Text files” as “Files of Type”
- Select file and click “Open”
- Make sure “Delimited” is selected and click “Next”
- Deselect “Tab” and select “Comma”
- Click “Next” and “Finish”
Another option is to use a tool called esxplot”. You can download the latest version here.
- Run: esxplot
- Click File -> Import -> Dataset
- Select file and click “Open”
- Double click host name and click on metric
As you can clearly see in the screenshot above the legend(right of the graph) is too long. You can modify that as follows:
- Click on “File” -> preferences
- Select “Abbreviated legends”
- Enter appropriate value
export VERSIONER_PYTHON_PREFER_32_BIT=yes
Limiting your view
In environments with a very high consolidation ratio (high number of VMs per host) it could occur that the VM you need to have performance counters for isn’t shown on your screen. This happens purely due to the fact that height of the screen is limited in what it can display. Unfortunately there is currently no command line option for esxtop to specify specific VMs that need to be displayed. However you can export the current list of worlds and import it again to limit the amount of VMs shown.esxtop -export-entity filenameNow you should be able to edit your file and comment out specific worlds that are not needed to be displayed.
esxtop -import-entity filenameI figured that there should be a way to get the info through the command line as and this is what I came up with. Please note that
VMWID=`vm-support -x | grepNow you can use the outcome within esxtop to limit(l) your view to that single GID. William Lam has written an article a couple of days after I added the GID section. The following is a lot simpler than what I came up with, thanks William!|awk '{gsub("wid=", "");print $1}'` VMXCARTEL=`vsish -e cat /vm/$VMWID/vmxCartelID` vsish -e cat /sched/memClients/$VMXCARTEL/SchedGroupID
VM_NAME=STA202G ;grep "${VM_NAME}" /proc/vmware/sched/drm-stats | awk '{print $
IOBlazer - storage micro-benchmark tool - run in VM - brand new baby from VMware Labs
IOBlazer is a multi-platform storage stack micro-benchmark. IOBlazer runs on Linux, Windows and OSX and it is capable of generating a highly customizable workload. Parameters like IO size and pattern, burstiness (number of outstanding IOs), burst interarrival time, read vs. write mix, buffered vs. direct IO, etc., can be configured independently. IOBlazer is also capable of playing back VSCSI traces captured using vscsiStats. The performance metrics reported are throughput (in terms of both IOPS and bytes/s) and IO latency.
IOBlazer evolved from a minimalist MS SQL Server emulator which focused solely on the IO component of said workload. The original tool had limited capabilities as it was able to generate a very specific workload based on the MS SQL Server IO model (Asynchronous, Un-buffered, Gather/Scatter). IOBlazer has now a far more generic IO model, but two limitations still remain:
A very useful new feature is the capability to playback VSCSI traces captured on VMware ESX through the vscsiStats utility. This allows IOBlazer to generate a synthetic workload absolutely identical to the disk activity of a Virtual Machine, ensuring 100% experiment repeatability.
http://labs.vmware.com/flings/ioblazer
IOBlazer evolved from a minimalist MS SQL Server emulator which focused solely on the IO component of said workload. The original tool had limited capabilities as it was able to generate a very specific workload based on the MS SQL Server IO model (Asynchronous, Un-buffered, Gather/Scatter). IOBlazer has now a far more generic IO model, but two limitations still remain:
- The alignment of memory accesses on 4 KB boundaries (i.e., a memory page)
- The alignment of disk accesses on 512 B boundaries (i.e., a disk sector).
A very useful new feature is the capability to playback VSCSI traces captured on VMware ESX through the vscsiStats utility. This allows IOBlazer to generate a synthetic workload absolutely identical to the disk activity of a Virtual Machine, ensuring 100% experiment repeatability.
http://labs.vmware.com/flings/ioblazer
Labels:
Bleeding Edge Tech
Thursday, October 28, 2010
Wednesday, October 27, 2010
Train Signal VMware vSphere Video Training
Train Signal VMware vSphere Video Training
| NEW! As a follow up to David Davis's best selling video series on VMware ESX Server, David has released an entirely new video training course covering VMware vSphere. The course is available from www.TrainSignal.com! This video series is over 17 hours and provides hands-on demonstration of VMware vSphere, from installation to advanced features. In the video series, David covers awesome new vSphere features like Fault Tolerance (FT), Host Profiles, Hot Add of CPU/RAM, and Data Recovery. To watch a free demo of the course, visit the Train Signal.com VMware vSphere video training website! You'll be glad you did. |
Monday, August 2, 2010
What is MultiCore Virtual CPU?
VMware multicore virtual CPU support lets you control the number of cores per virtual CPU in a virtual machine. This capability lets operating systems with socket restrictions use more of the host CPU's cores, which increases overall performance.
You can configure how the virtual CPUs are assigned in terms of sockets and cores. For example, you can configure a virtual machine with four virtual CPUs in the following ways:
* Four sockets with one core per socket
* Two sockets with two cores per socket
* One socket with four cores per socket
Using multicore virtual CPUs can be useful when you run operating systems or applications that can take
advantage of only a limited number of CPU sockets. Previously, each virtual CPU was, by default, assigned
to a single-core socket, so that the virtual machine would have as many sockets as virtual CPUs.
When you configure multicore virtual CPUs for a virtual machine, CPU hot Add/remove is disabled.
For more information about multicore CPUs, see the vSphere Resource Management Guide. You can also search the VMware KNOVA database for articles about multicore CPUs.
CAUTION You must assign a value to configuration parameter keywords. If you don't assign a value, the
keyword can return a value of 0, false, or disable, which can result in a virtual machine that cannot power on.
Prerequisites
IMPORTANT To use the VMware multicore virtual CPU feature, you must be in compliance with the
requirements of the operating system EULA.
* Verify that the virtual machine is powered off.
* Verify that you have virtual machine hardware version 7 or later.
* Verify that the total number of virtual CPUs for the virtual machine divided by the number of cores per
socket is a positive integer.
You can configure how the virtual CPUs are assigned in terms of sockets and cores. For example, you can configure a virtual machine with four virtual CPUs in the following ways:
* Four sockets with one core per socket
* Two sockets with two cores per socket
* One socket with four cores per socket
Using multicore virtual CPUs can be useful when you run operating systems or applications that can take
advantage of only a limited number of CPU sockets. Previously, each virtual CPU was, by default, assigned
to a single-core socket, so that the virtual machine would have as many sockets as virtual CPUs.
When you configure multicore virtual CPUs for a virtual machine, CPU hot Add/remove is disabled.
For more information about multicore CPUs, see the vSphere Resource Management Guide. You can also search the VMware KNOVA database for articles about multicore CPUs.
CAUTION You must assign a value to configuration parameter keywords. If you don't assign a value, the
keyword can return a value of 0, false, or disable, which can result in a virtual machine that cannot power on.
Prerequisites
IMPORTANT To use the VMware multicore virtual CPU feature, you must be in compliance with the
requirements of the operating system EULA.
* Verify that the virtual machine is powered off.
* Verify that you have virtual machine hardware version 7 or later.
* Verify that the total number of virtual CPUs for the virtual machine divided by the number of cores per
socket is a positive integer.
Labels:
Bleeding Edge Tech
VMware Log Locations & Descriptions
The vCenter Server logs can be viewed from:
- The vSphere Client connected to vCenter Server (click Home > Administration > System Logs)
- The vSphere Client connected to VirtualCenter Server (click Administration > System Logs).
The logs are located in %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs, which translates to C:\Documents and Settings\All Users\Application Data\VMware\VirtualCenter\logs in Windows 2003 and C:\ProgramData\VMware\VMware VirtualCenter\Logs in Windows 2008.
The vCenter Server logs appear as vpxd-xx.log.
The vpxd-profiler-xx.log is used for the VPX Operational Dashboard (VOD),which can be accessed via https:///vod/index.html .
• Vmkernel – /var/log/vmkernel – records activities related to the virtual machines and ESX server.
• Vmkernel Warnings – /var/log/vmkwarning – This log is a copy of everything marked as a warning or higher severity from vmkernel log. It is much easier to look through this for warnings and errors, instead of filtering through the full information in the vmkernel logs.
• Vmkernel Summary – /var/log/vmksummary – Used to determine uptime and availability statistics for ESX Server; human-readable summary found in /var/log/vmksummary.txt
• ESX Server host agent log – /var/log/vmware/hostd.log – Contains information on the agent that manages and configures the ESX Server host and its virtual machines (Search the file date/time stamps to find the log file it is currently outputting to).
• Service Console – /var/log/messages – This log is the log from the Linux kernel (service console), which is generally only potentially useful in the case of a host hang, crash, authentication issue, or 3rd party app acting up. This log has NOTHING to do with virtual machines. The SERVICE CONSOLE (red hat kernel) has NO awareness of the VMs (worlds) running on the VMKERNEL.
Location of Logs & Brief note on that
• Web Access – /var/log/vmware/webAccess – Records information on Web-based access to ESX Server.
• Authentication log – /var/log/secure – Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd daemon.
• VirtualCenter agent – /var/log/vmware/vpx – Contains information on the agent that communicates with VirtualCenter.
• Virtual Machines – The same directory as the affected virtual machine’s configuration files; named vmware.log – Contain information when a virtual machine crashes or ends abnormally.
/var/log/vmkernel Vmkernel Records activities related to the virtual machines and ESX host
/var/log/vmkwarning Vmkernel Warnings A copy of everything marked as a warning or higher severity from vmkernel log. Easier to look through than vmkernel log
/var/log/vmksummary Vmkernel Summary Used for avaialability and uptime statistics. Human-readable summary in vmksummary.txt
/var/log/vmware/hostd.log Host Agent Log Contains information on the agent that manages and configures the ESX host and its virtual machines
/var/log/vmware/vpx VirtualCenter Agent Contains information on the agent that communicates with VirtualCenter
/var/log/messages Service Console Log from the Linux kernel. Useful for underlying Linux issues. The kernel has no awareness of VMs running on the VMkernel
/var/log/vmware/esxcfg-boot.log ESX Boot Log ESX Boot log, logs all ESX boot events
/var/log/vmware/webAccess Web Access Records information on Web-based access to ESX Server
/var/log/secure Authentication Log Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd daemon
/var/log/vmware/esxcfg-firewall.log ESX Firewall Log Contains all firewall rule events
/var/log/vmware/aam High Availability Log Contains information related to the High Availability (HA) service
/var/log/vmware/esxupdate.log ESX Update Log Logs all updates completed using the esxupdate tool
There’s a new Knowledgebase article on this here: VMware KB: http://kb.vmware.com/kb/1021806 Location of log files for VMware products
Labels:
Logs
Monday, June 14, 2010
Troubleshooting Virtual Machine snapshot problems
A nice guide on Troubleshooting VM snapshot problems --> http://is.gd/ckwDc
This troubleshooting guide explains basic concepts about Virtual Machine snapshots and different troubleshooting paths depending on the problem. This guide was designed for ESX3.5 and extra considerations have to be taken if working with ESX3.5i or ESX4(i). The formulas and most of the procedures described in this document were created by Ruben as part of a continuous troubleshooting improvement process.
Ruben is also creator of SnapVMX utility.
While troubleshooting Virtual Machine (VM) snapshot problems sometimes it is important to retrieve a lot of information in order to take the most appropriate decision in accordance with the situation. That collection and arrangement of information may take a long time especially if the VM has many snapshots.
SnapVMX was created to speed up the troubleshooting process bringing you instantaneously all the information that you need to evaluate the situation and take the correct decision, reducing the downtime to the bare minimum needed to solve the problem,
Source : Eric Blog
Also Try below VMware KB TV - Consolidating snapshots (VMware KB 1007849) - video below
This troubleshooting guide explains basic concepts about Virtual Machine snapshots and different troubleshooting paths depending on the problem. This guide was designed for ESX3.5 and extra considerations have to be taken if working with ESX3.5i or ESX4(i). The formulas and most of the procedures described in this document were created by Ruben as part of a continuous troubleshooting improvement process.
Ruben is also creator of SnapVMX utility.
While troubleshooting Virtual Machine (VM) snapshot problems sometimes it is important to retrieve a lot of information in order to take the most appropriate decision in accordance with the situation. That collection and arrangement of information may take a long time especially if the VM has many snapshots.
SnapVMX was created to speed up the troubleshooting process bringing you instantaneously all the information that you need to evaluate the situation and take the correct decision, reducing the downtime to the bare minimum needed to solve the problem,
Source : Eric Blog
Also Try below VMware KB TV - Consolidating snapshots (VMware KB 1007849) - video below
Labels:
Guides,
Step-By-Step-Guide
Using MOB- (Managed Object Browser) --> Ops Panel for ESX
I was recently reading Eric Sloof article,
Where you can go and edit (index.html - which opens as ESX server home page) customize by using MOB (Via Java Scripting).. here is the cool video by Eric.
The Operations Panel is a script tool, which runs on the client browser and extends the default ESX server web page with a short list of all available virtual machines. It gives the user the ability to perform simple power operations (start, stop, suspend, resume). Easily accessible user interface for some of the most common operations on an ESX host, available directly from the ESX home page.
Ops Panel for ESX from Eric Sloof NTPRO.NL on Vimeo.
Where you can go and edit (index.html - which opens as ESX server home page) customize by using MOB (Via Java Scripting).. here is the cool video by Eric.
The Operations Panel is a script tool, which runs on the client browser and extends the default ESX server web page with a short list of all available virtual machines. It gives the user the ability to perform simple power operations (start, stop, suspend, resume). Easily accessible user interface for some of the most common operations on an ESX host, available directly from the ESX home page.
Ops Panel for ESX from Eric Sloof NTPRO.NL on Vimeo.
Labels:
Bleeding Edge Tech,
CLI,
Step-By-Step-Guide
Top 10 Free vSphere ESX Tools and Utilities
Top 10 Free vSphere ESX Tools and Utilities
http://www.kendrickcoleman.com/index.php?/Tech-Blog/top-10-free-vsphere-esx-tools-and-utilities.html
http://www.kendrickcoleman.com/index.php?/Tech-Blog/top-10-free-vsphere-esx-tools-and-utilities.html
Labels:
Bleeding Edge Tech,
Guides
64GB Addressable Memory Limit on ESX 3.x Host
Prior to ESX 3.5 Update 3, the ability to address more than 64GB of memory on ESX Server 3.5 is suppressed by default. In a standard installation, a 36bit MTRR mask is forced, even though the machine may support 40bit mask values. This means that the ESX Server may see any memory above 64GB as memory that is in use. For example, if an ESX server has 256GB of RAM, the Memory Usage counter displays 192GB in use and only 64GB free. If you attempt to create a virtual machine using memory exceeding the available 64GB of memory, you see an Insufficient Memory error. This condition is documented in the following location: http://www.vmware.com/support/vi3/doc/vi3_esx35u3_rel_notes.html
For more details & Resolution refer Jason Boche Article below..
http://www.boche.net/blog/index.php/2010/05/24/esx-3-x-host-64gb-addressable-memory-limit/
For more details & Resolution refer Jason Boche Article below..
http://www.boche.net/blog/index.php/2010/05/24/esx-3-x-host-64gb-addressable-memory-limit/
Labels:
Step-By-Step-Guide,
TrobuleShoot
Friday, June 11, 2010
Monday, May 24, 2010
How to power off an unresponsive VMware ESX virtual machine
Sometimes Guest OS will go stale / hang due to various reasons..
follow the below VMware KBTV Article to handle the situation..
follow the below VMware KBTV Article to handle the situation..
Labels:
Step-By-Step-Guide,
TrobuleShoot
Subscribe to:
Posts (Atom)