Vsphere ha virtual machine monitoring error

Обновлено 01.04.2019

Всем привет сегодня расскажу, как решается и из-за чего выскакивает ошибка vsphere ha virtual machine monitoring error и vsphere ha virtual machine monitoring action. Данная ошибка вполне может перезагрузить виртуальную машину, нештатно завершив все рабочие процессы, ладно если это случиться в вечернее время, с минимальными последствиями для клиентов, а если в самый час пик, это очень сильно ударит по репутации компании и может повлечь денежные убытки.

Вот более наглядное представление этих ошибок в VMware vCenter 5.5.

Видим сначала идет предупреждение и потом alert

Анализ log файла

Сначала нужно проанализировать лог файл виртуальной машины, для этого щелкаем правым кликом по datastore и выбираем browse datastore

Переходим в нужную папку виртуальной машины и находим там файл vmware.log

Этот файл vmware.log, нам нужно скачать, сделать это можно к сожалению только на выключенной виртуальной машине, щелкаем по нему правым кликом и выбираем Download

Указываем место куда нужно закачать ваш файл, для дальнейшего изучения. Все ошибки в данном файле в большинстве случаев сводятся к необходимости обновить vmware tools

То же самое вы можете увидеть и на Vmware ESXI 6.5. (VMware Tools is not installed on this virtual machine)

Обновление vmware tools

Напомню vmware tools это пакет драйверов который устанавливается внутри виртуальной машины для лучшей интеграции и расширения функционала. Как обновить vmware tools в VMware ESXI 5.5 я рассказывал ранее. Еще отмечу, что вначале вам придется удалить Vmware Tools из гостевой операционной системы, так как смонтировать диск с дистрибутивом для обновления вы не сможете, так как поле будет не активно.

Так же если вы будите медлить с решением данной проблемы, вы будите постоянно ловить синий экран с кодом 0x00000050. При его анализе он будет ругаться на драйвера.

Надеюсь что вы теперь поняли из за чего происходит alert vsphere ha virtual machine monitoring error. Материал сайта pyatilistnik.org

You can monitor your cluster for HA related issues by setting up alarms. The are a number of default alarms, including these cluster alarms:

• Cannot find master – Default alarm to alert when vCenter Server has been unable to connect to a vSphere HA master agent for a prolonged period
• Insufficient failover resources – Default alarm to alert when there are insufficient cluster resources for vSphere HA to guarantee failover
• Failover in progress – Default alarm to alert when vSphere HA is in the process of failing over virtual machines

There are also these virtual machine alarms:

• VM monitoring error – Default alarm to alert when vSphere HA failed to reset a virtual machine
• VM monitoring action – Default alarm to alert when vSphere HA reset a virtual machine
• Failover failed – Default alarm to alert when vSphere HA failed to failover a virtual machine

And there is the following host related alarm:

• HA status – Default alarm to monitor health of a host as reported by vSphere HA

To configure these default alarms, using the vSphere client, highlight the vCenter server object, then click onto the Alarms tab:

As with other alarms, you can configure it so a notification email or snmp trap is sent if the alarm is triggered, or you can have it take one of these other actions:

• Run a command
• Power on VM
• Power off VM
• Suspend VM
• Reset VM
• Migrate VM
• Reboot Guest VM
• Shutdown Guest VM

Sending Notification Emails and SNMP Traps

Remember that if you are choosing the send notification emails or SNMP traps then you need to configure the appropriate vCenter server settings. For email:

And for SNMP:

Monitoring a HA Cluster

Along with the alarms you can configure, there are a few other ways in which you can monitor your cluster. The cluster summary tab has a lot of information regarding the health of the cluster:

The ‘Cluster Status’ link will show any current issues with the cluster’s hosts, it will show how many VMs are protected by HA and will show which hosts are using which datastores for their datastore heartbeating:

The ‘Configuration Issues’ link will display any current configuration issues with the cluster:

In the previous post setting up and configuring alarms in vCenter 5 Part 1 we looked at the initial configuration.  We are now going to run through some of the default alarms, with some suggested thresholds.

Cannot Connect To Storage why would we want to configure this? Well essentially this is a per host setting.  If the host loses connection to the storage then the VM’s will be restarted using HA.  Big deal you say, I can see that in vCentre.  Well it also manages ‘lost storage path redundancy’ and ‘degraded storage path redundancy’ so if you have an if your ESXi host has multiple connections to it’s storage, you will be notified if one of these is lost.

Datastore Usage On Disk quite an important one.  From the presented LUN how much space has been provisioned as a Datastore.  I recommend always asking for slightly more than need e.g. if you need 1TB for a Datastore, ask for an extra 25%.  Then when the Datastore is provisioned only use 1TB so you have room for expansion quickly and easily if needed.  With this in mind, I set the Warning to 90% and Critical to 95% so I have some room to either more VM’s around either by Storage vMotion or Cold Migration.

Host CPU Usage with this alarm, I generally alert at Warning 75% for 15 mins and then Critical for 10 mins.  The rational behind this is that I would want to investigate the VM’s CPU utilisation to see if it is a one off event causing the high usage or if we need to look at introducing more processing power into the cluster.

Host Error perhaps the most important one, this is what vCentre relies on to monitor host alarms!

Host Memory Usage similar to CPU usage, I generally set Warning to 90% for 15 mins and Critical for 10 mins.  Again I would want to investigate the host memory usage to ensure that we have sufficient resources for a host failure.

Host Memory Status not be confused with ‘Host Memory Usage’ this monitors the physical DIMMS.

Host Process Status again not to be confused with ‘Hot CPU Usage’ this monitor the physical processor hardware.

License Capacity Monitor I like this alarm, it’s great for items such as Site Recovery Manager or Operations Manager.  It lets you know if you are trying to protect or manage more VM’s than you are licensed for.

Virtual Machine CPU Usage I use the same alarms settings for ‘Host CPU Usage’ so that if a VM is using more than 75% of it’s CPU capacity for over 15 minutes, I would want to identify if this is a one off or if extra resources are required.

vSphere HA Failover In Progress this resides on the nice to have.  If for some reason none of your other alarms work then at least you know that a VM has been restarted by HA.

vSphere HA Virtual Machine Monitoring Error this alarm works in conjunction with Virtual Machine Monitoring.  I tend to leave VM Monitoring Only and Medium and then change individual VM’s monitoring to High if required.  If you have this set to high for all servers then it can cause alarms when backup software rolls back snapshots depending on how big the VM is.

Hopefully these alarms shouldn’t need any explanation, as they should ALWAYS be enabled.

Host Battery Status
Host Connection And Power State
Host Connection Failure
Host Hardware Fan Status
Host Hardware Power Status
Host Hardware System Board Status
Host Hardware Temperature Status
Insufficient vSphere HA Failover Resources
Network Connectivity Lost
Network Uplink Redundancy Degraded
Network Uplink Redundancy Lost

Naturally, this isn’t a complete list of alarms, however it is the default alarms that I would configure in most, if not all environments.  Every environment is different and you may use more or less alarms than I have mentioned.

Don’t forget that depending on which vSphere licenses you have might see extra default alarms for items such as FT.  Also when you install additional components e.g. SRM you will get even more alarms to have a play around with.