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

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:

1. How to identify the problem using specific performance counters.
2. 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.

vsphere41-performance-troubleshooting.pdf (755.0 K) 

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.

Resolution

Who is affected

1. 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.
2. 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.

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. 

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:

1. Log in to VirtualCenter.
2. Select the ESX Server host where you want restart hostd.
3. Select the Configuration tab.
4. Select Virtual Machine Startup/Shutdown.
5. Select Properties.
6. 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:

1. Log in to the ESX Server service console as root.
2. At the command line run vimsh.
3. At the [/] prompt, type:
   hostsvc/autostartmanager/enable_autostart 0
    
4. Type exit. You can now safely restart mgmt-vmware (hostd).

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/

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..

VMware Update manager does not scan hosts??? Disable Internet Explorer Enhanced Security Configuration on Win2k8

VMware update manager hated me and wouldn’t scan any of my hosts, one of the many fixes I was trying was making sure that my VMware Update Manager server could reach the patch stores to download updates and do patch checks and so decided to make sure of this I wanted to remove the painfully irritating Internet Explorer Enhanced Security Configuration. Now before I get loads of comments saying this is dangerous etc etc and that it’s a security risk,I know it is but for testing purposes I wanted to do it so I did. Now the point of this blog is that to disable it isn’t as easy as it used to be in 2003 as you used to just:

• Go to Control Panel
• Add/Remove Programs, 
• Add/Remove Windows Components on the left hand side

• Untick it from the drop down list

But for Windows Server 2008 I couldn’t find it anywhere in the features drop down lists which has replaced the Windows Components in Server 2008. Fortunately while on another Server 2008 server I noticed the place to disable it. In the Server Manager root page under the Security Information section is Configure IE ESC

 All you need to do is click on this link and disable it for either Administrators and/or for Users. I only needed for Administrators so this is what I selected for the testing.

Source : EMC Feeds

Rename VMDK files – else you may have to experience Backup Problems

What if you end up with the same vmdk file name on different datastores?

A simple case scenario that can happens:

A single VM has several hard disk attached to it. The hard disk VMDK files are located on different datastores. When creating a new hard disk which location is on different datastore to a VM, the name given to this VMDK is the same as the first VMDK.

For exemple, you VM has a disk called TS01.vmdk which is located on DATASTORE1, and you create a second disk located on DATASTORE2. This disk takes the same name as the first one…. This is not a problem for VMware, but it is for third party backp products like Symantec Backup Exec 2010. In fact what happens to the backup job wanting to backup a VM like this? The VMDK is marked as a corrupted and the job fails, so it's impossible to restore either.

What's the solution? VMware KB had give me an simple answer what to do in the case like this. You'll have to use vmkfstools via command line to do the job. Don't worry, it's not difficult.

How to:

01. First, make sure that the VM has NO Snapshots. Then power down your VM go to menu Edit Settings.

On the next screen you just go to the hard disk you want to rename. Select the hard disk and click the remove button. The screen change and you have the possibility to check a radio button to delete the disk from datastore. Don't check this radio button. Otherwise your disk gets deleted..

02. Validate your choice on clicking OK.

03. Then you must connect to the console of the ESX server to which the datastore2 is attached to. Use putty or go directly to the server room.

04. Via putty navigate to the folder where the hard disk is located and execute following command:
vmkfstools -E <old_name> <new_name>
So in our case the command looks like this (I'm renaming from ts01.vmdk to ts01_2.vmdk):

vmkfstools -E ts01.vmdk ts01_2.vmdk

05. Then go to your VI client and add the renamed disk back to the virtual machine. In the Inventory browser by right clicking the datastore and where the VM is stored and select "Browse Datastore", select the folder of the VM than right click the vmx file and select "Add to Inventory".

This works fine for ESX 4, but to be able to use it with ESXi 4 you have several choices:

01. You can use the unsupported (Tech Support Mode) to get to the console of ESXi 4 since the CLI tools won't work for writing data in the free version of ESXi 4.

02. If your ESXi 4 is licensed with paid VMware License you can use PowerCLI or VMA to do the job.

Source    :    www.vladan.fr

How to Decode MCE from PSOD (ESX dump) to identify the H/w Errors

Next time you see a PSOD (Pink Screen on Death) for ESX Server..
Look for any MCE (Machine Check Error) in the PSOD screen to isolate H/w issues.

MCE errors are always indication of some H/w failure..

Decoding the MCE:
For AMD CPUs you can use MCAT utility to decode the MCE for you..
www.amd.com/us-en/assets/content_type/utilities/mcatsetup.exe

For Intel CPUs you need to convert the MCE from
Hexadecimal to Binary and decode the error manually..

Watch the Video for how to decode the MCE for AMD Processors



Source : VMware KB - 1005184

Performance Monitoring of LUN, HBA, VM & for Which Threshold values, you should show concern

The esxtop utility can be used to measure how much I/O is moving across various devices. The esxtop utility is interactive. As such, pressing certain keys changes the view.

Configuring monitoring using esxtop

To monitor storage performance per HBA:

1. Start esxtop by typing esxtop at the command line.
   
2. Press d to switch to disk view (HBA mode).
   
3. Press f to modify the fields that are displayed.
   
4. Press b, c, d, e, h, and j to toggle the fields and press Enter.
   
5. Press s, then 2 to alter the update time to every 2 seconds and press Enter.
   
6. See Analyzing esxtop columns for a description of relevant columns.

 Click below --> "Read More" for Full Article (Tolerable Threshold Values in Real time)..

VMware ESXi 4 Log Files

Source : /www.simonlong.co.uk/blog/

Like most VI Admins, I've been using VMware ESXi quite a lot more lately and I'm slowly coming across things that are different to how they are in ESX. Log files being one of these differences.
With the absence of the Service Console, ESXi presents a slightly different architecture. If you haven't yet read The Architecture of VMware ESXi, I would recommend having a good read through.
Here is the common log file structure in ESX (Source)

 Click below --> "Read More" for Full Article (Log File Geometry & Snippets)..

Re-Connect NFS Datastore without Restarting ESX Host (in case NFS Physical connection is lost & restored)

Try below VMware KB  or another work around below..
(Ensure vmkping x.x.x.x) - where x.x.x.x is your NAS IP - is pinging

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005057


Another workaround - below

NFS is a great storage solution within a VMware vSphere environment. But when the connection to the NFS server is lost, you’re in big trouble. In most circumstances some virtual machines are still connected to the NFS Datastore and since it’s in use, you cannot delete and recreate it. I’ve tried this by using the vSphere Client and trough the command line but didn’t succeed. In the end there’s no other alternative than rebooting the ESX host, or is there… If you want to find out how to remount an NFS Datastore you may watch below video. By Eric Sloof

Actual Trick is - NFS data store IP was x.x.x.x, he created a host name (using /etc/hosts file or DNS or alias host name on DNS) to fool the vCenter, then added host name when adding NFS source. vCenter thinks it's getting NFS from different Source..

May be it's a little dragging video, wait till end of video to see the insight

How to troubleshoot Pink Screen on Death (PSOD) in ESX

Source : VMware KB, VMworld PSOD Guide, TechTarget

VMware might not want to get into Blues like Microsoft much famed BSOD (Blue Screen on Death). So they named it as PSOD (Pink Screen on Death).. LOL..

As you know PSOD crash normally could have no shortcut to find the source of problem, VMware tried it's best to make to straight, possible PSOD causes as mentioned below

1) Hardware Faults
2) Host Faults
3) VMM Faults
4) Guest Operating System Faults
5) Application Faults

  How to Capture the PSOD crash dump (By default PSOD dump is saved on /root)

1) type "vm-support" (on # Prompt) without any options. The utility will run and create a single Tar file that will be named  "esx-xxxxxx..tgz".

2) Alternatively, you can generate the same file by using the VMware Infrastructure Client (VI Client). Select  Administration, then Export Diagnostic Data, and select your host (VirtualCenter data optional) and a directory on your local PC to store the file that will be created. 


You may follow these steps to resolve the issue

 Click below --> "Read More" for Full Article

VMDK Related - Simple Stuff - but good to read & keep in mind

I guess, you may use Mr.Mattr workaround (below) in other cases, like data recovery / repair file system times as well. - Source : www.breathalize.co.uk - by mattr

I was upgrading the memory in a Windows 2000 VM to 8GB, and had to alter the boot.ini to use more than 4GB. Unfortunately I was doing this remotely and during the save process my VPN died. When I rebooted the server I was faced with the dreaded ‘NTBTLDR.EXE is missing’. 

Now I knew that the problem must lie with the boot.ini, but how to get at it? Because I was remote I did not have a Windows 2000 disk to get a recovery console up and I needed to get the server up and running again. I then realized that I did not need to boot from a CD to get to the VM’s hard drive.

I shut the VM off again, and switched to other VM on same host. In Edit Settings, I simply added the vmdk of the troubled VM to the other VM and rescanned for the disk in Disk Management. Lo and behold the disk appeared and I could access the boot.ini file – I had managed to add a space at the beginning of the file during the save process which was causing the problem.

I rectified the file, removed the disk from the spare server and then the vmdk from the client. I crossed my fingers and restarted the VM … and gratefully saw the windows splash screen appear. If this had been a physical box I would not have had a chance of fixing this remotely, and even on site there would have been much more time expended on finding a chassis with spare slots, array controller configurations etc. so it goes to show even the most basic functions of VMware are worth the effort of putting it in in the first place  

Restarting the Management agents on an ESX or ESXi Server (May Solve all below symptoms)

Symptoms / Problems 

• Cannot connect ESX to VirtualCenter
• Cannot connect ESX to vCenter Server
• Cannot connect directly to ESX Server from the VMware Infrastructure Client
• Cannot connect directly to the ESX Server from the vSphere Client
• You cannot stop or start a virtual machine
• A virtual machine is shown as running in VirtualCenter when it is not
• VirtualCenter shows the error:
  
  
  
  Virtual machine creation may fail because agent is unable to retrieve VM creation options from the host

Purpose 

For troubleshooting purposes, it may be necessary to restart the management agents on your ESX Server. This article provides you with the steps to restart the management agents (mgmt-vmware and vmware-vpxa) directly on ESX or ESXi.

This article applies ESX 3 and ESX 4, as well as ESXi 3 and ESXi 4.

Caution: Restarting the management agents may impact any tasks that may be running on the ESX or ESXi host at the time of the restart. For more information about identifying tasks running on an ESX or ESXi host, see Collecting information about tasks in VMware ESX and ESXi (1013003).

Resolution :

Click below --> "Read More" for Full Article (How to restart Mgt agent on ESX & ESXi)..

Changing VirtualCenter log locations

LoDuring the initial setup of vCenter, you might have chosen LOG file location to default, which in turn may fill your OS Drive and cause the bottleneck to vCenter OS performance in future..

It's advised to change the vCenter LOG file location to different (not OS partition) & let the OS breathe..

By default (Windows 2003) log files are stored in “C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs”, and for Windows 2008 log files are stored in “C:\ProgramData\VMware\VMware VirtualCenter\Logs”.

Purpose 

This article provides steps to change the location in which VirtualCenter logs are kept.

Resolution 

Source VMware KB - 1009145 - Link here

While changing Preferred Path on Storage Adapter --> Unable to cast object of type ‘LogicalUnitPolicy’ to type ‘FixedLogicalUnitPolicy’

 
Source - http://www.simonlong.co.uk/
When trying to change the Preferred Path on Storage Adapter I was greeted with the following Error message

Unable to cast object of type ‘LogicalUnitPolicy’ to type ‘FixedLogicalUnitPolicy’

I checked my other Storage Adapters and these too gave me the same error.
The Fix
To fix this problem all you need to do is Rescan the Storage Adaptors using the following steps

1. In the vSphere Client, select the Host which has the Storage Adaptors that are giving you the error and click the Configuration tab.
2. In the Hardware panel, select Storage Adapters
3. Select one of your Storage Adaptors and click Rescan above the Storage Adapters panel.
4. Perform Step 3 for the rest of your Storage Adapters.

When you Power on a VM --> Error "The object has already been deleted or has not been completely created"

Problem (Article source -- http://www.simonlong.co.uk)
When trying to Power On an old VM I was greeted with this message:

I checked the Datastore and everything seemed to be present and correct. I tried to migrate the VM to a different Host, but again I was shown this error. A quick Google didn't show up anything useful so I decided to check the logs.
running the command  tail /var/log/vmware/hostd.log -f whist trying to Power On the VM flagged these error messages:

• [2010-03-24 12:11:10.547 'BaseLibs' 129907632 info] readlink /var/run/vmware/7f0f49adb5092b09694cdf456a488d6c: No such file or directory
• [2010-03-24 12:11:10.547 'BaseLibs' 129907632 info] readlink /var/run/vmware/%2fvmfs%2fvolumes%2f4ad45c8d%2ddb2eadd5%2d411f%2d00237d3c8b86%2fTEST%2dVWB01%2fTEST%2dVWB01%2evmx: No such file or directory

Solution

Remove the troubled Virtual Machine from the Inventory:

• Display the virtual machine in the inventory.
• Right-click the virtual machine and select Remove from Inventory.
• To confirm that you want to remove the virtual machine from the inventory, click OK.

Re-add the Virtual Machine back into vCenter:

• Browse the datastore where the VM's files are located
• Right Click on the VM's .vmx file and select Add to Inventory
• Follow the Wizard

Once you can see the VM in vCenter, try and power it on. Hopefully this should have fixed your issue.

APD (All Paths Dead) --> important vSphere 4 storage bug is solved in patch ESX400-200912401-BG

Article Source from xtravirt.com

Chad Sakac over at http://virtualgeek.typepad.com already blogged about the APD bug in December last year. You can find his post here.

Just a short quote from Chad his post about the symptoms of this APD bug:

Recently saw a little uptick (still a small number) in customers running into a specific issue – and I wanted to share the symptom and resolution.   Common behavior:

• They want to remove a LUN from a vSphere 4 cluster
• They move or Storage vMotion the VMs off the datastore who is being removed (otherwise, the VMs would hard crash if you just yank out the datastore)
• After removing the LUN, VMs on OTHER datastores would become unavailable (not crashing, but becoming periodically unavailable on the network)
• the ESX logs would show a series of errors starting with “NMP”

Examples of the error messages include:

“NMP: nmp_DeviceAttemptFailover: Retry world failover device "naa._______________" – failed to issue command due to Not found (APD)” “NMP: nmp_DeviceUpdatePathStates: Activated path "NULL" for NMP device "naa.__________________".

What a weird one…   I also found that this was affecting multiple storage vendors (suggesting an ESX-side issue).  You can see the VMTN thread on this here.

We found out about this issue during a big storage project. We where creating a lot of new LUNs and where removing a lot of the old LUNs. If you remove a LUN on a way not mentioned in Chad his post:

This workaround falls under “operational excellence”.   The sequence of operations here is important – the issue only occurs if the LUN is removed while the datastore and disk device are expected by the ESX host.   The correct sequence for removing a LUN backing a datastore.

• In the vSphere client, vacate the VMs from the datastore being removed (migrate or Storage vMotion)
• In the vSphere client, remove the Datastore
• In the vSphere client, remove the storage device
• Only then, in your array management tool remove the LUN from the host.
• In the vSphere client, rescan the bus.

So when we used the workaround described above, everything went fine. But at my current employer, we use a large LeftHand iSCSI SAN.  One of the great things of Lefthand SAN is the ability to move LUNs between different clusters. With the APD bug, we couldn’t use this option anymore.
When we discovered this APD bug we contacted VMware Support. After a couple of weeks we received an e-mail with the following fix.

I can now confirm that the APD (All paths dead) issue has been resolved by a patch released as part of P03.
To install this patch, please upgrade your hosts to vSphere Update 1 and use Update Manager to install the latest patches.
Please ensure that ESX400-200912401-BG is installed as this resolves the APD problem

We upgraded one of our clusters to Update 1 and installed the latest patches including the ESX400-200912401-BG patch. After installing the patch, we did some tests and I can confirm that the APD bug is history!!

For Step-by-Step Upgrade Sequence Guide on how to update APD patch? - Click This Link

More info about the patch can be found here:

• http://kb.vmware.com/kb1016291 

For the readers who cannot upgrade to vSphere Update 1 and the latest patches, you can find some workarounds here on below:

• http://kb.vmware.com/kb1016626
• http://kb.vmware.com/kb1015084
• http://virtualgeek.typepad.com

5 things you need to know about VMware vSphere Alarms

By David Davis from http://www.virtualizationadmin.com

Virtualization is an awesome thing but just like any piece of your IT infrastructure, you need to be alerted when something goes wrong (and ideally, before something goes wrong). VMware vSphere has a powerful alerting or notification system built in called "Alarms" (call them whatever you want but if you want to use them in vSphere, you should start calling them "alarms"). Alarms can be configured to tell you when specific events, conditions, or states occur within the vSphere inventory.

Let's learn the 5 most important things you need to know about vSphere alarms.

1. vSphere has 33 pre-configured and enabled alarms
2. Alarms trickle down the vSphere inventory hierarchy
3. vSphere has a Triggered Alarms and an Alarm Definitions View
4. vSphere has 8 Alarm monitoring types
5. An Alarm is defined by with a type, trigger, and action

In point #5, we learn that creating a new alarm is easy by following my simple 7 steps. Overall, it is crucial for vSphere Admins to understand how alarms work in order to properly monitor their virtual infrastructure and to be alerted of issues that need to be resolved. I encourage you to spend a few minutes working with vSphere alarms!
Step by Step Guide to learn above 5 Things --> Link here from www.virtualizationadmin.com