Loading

×Sorry to interrupt
CSS Error

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

Skip to main content

My Subscriptions

Loading

Knowledge Base

HP Automatic Server Recovery (ASR) in an ESX environment (1010842)

Last Updated: 3/20/2024Categories: TroubleshootingTotal Views: 27194Language:
Chinese (Simplified)English

2 like this article

Subscribe to get an email
newsletter with new updates

2 people found this helpful Please provide article feedback:

Symptoms

If an ASR event occurs, the server hardware is restarted and IML shows the message:

An ASR has occurred

Purpose

This article provides information about HP Automatic Server Recovery (ASR) and ASR events.

Resolution

What is ASR's function?
ASR is an HP-provided capability enabling system reboots if the hardware determines that the operating system has become unresponsive. This can reduce downtime to business-facing applications.

How does it work?
ASR is comprised of two components on an ESX host: A hardware heartbeat timer and a Health Monitor running in the operating system. The heartbeat timer, by default, is set to 10 minutes and begins countdown from there. The Health Monitor is responsible for frequently reloading the timer. On ESX hosts, this agent runs in the Service Console and is usually installed as part of HP Insight Manager.

If the timer reaches zero, ASR assumes that the operating system has become unresponsive and reboots the server.

ASR in an ESX environment
ESX hosts are comprised of two primary components: The VMkernel and the Service Console. At a high level, the VMkernel is responsible for the overlying virtual machines, while the Service Console is responsible for providing a management interface to the ESX host. Agents can be installed in the Service Console to provide management instrumentation and other functions, including the Health Monitor.

The Health Monitor running in the Service Console may occasionally fail to reset the heartbeat timer. Reasons include:

A system failure

The Service Console on an ESX host has too high a load, preventing the Health Monitor from getting CPU time

A purple diagnostic screen error

When to disable ASR on ESX hosts
There are three primary arguments for disabling ASR on ESX hosts:

Unintended virtual machine outages: If the heartbeat timer reaches zero as a result of a problem within the Service Console (for example, CPU or memory utilization or an agent failure), ASR may determine that the server has failed, even if the overlying virtual machines are still functioning. In this case, attempt to migrate the virtual machines off the host prior to a host restart. If ASR is enabled, the host is rebooted and the overlying virtual machines fail, resulting in an outage to business-facing applications that may have been avoided (by migrating or working with support) or minimized (by scheduling a maintenance window in the event that migration fails).

Loss of diagnostic data: If the heartbeat timer reaches zero as a result of a purple diagnostic screen error and ASR reboots the system, it may become impossible to determine the root cause of the ASR reboot since diagnostic data related to the crash is lost upon restart. In addition, if there is a delay between the service console becoming unresponsive and the resultant purple diagnostic screen error, it is possible that ASR could reboot the system prior to the purple diagnostic screen error being generated. This could circumvent the generation of the purple diagnostic screen error and related diagnostic data. The purple diagnostic screen error contains a wealth of valuable information that can aid in pinpointing a root cause.

Increasing the ASR timer may not help: The ASR timer can be increased from 10 to as high as 30 or 60 minutes. However, doing so may reduce ASR's effectiveness. Its intent is to minimize downtime, and 30 or 60 minutes is a long time for a system to be unresponsive without operator intervention. Further, even with a timer set that high, ASRs can still occur, which will impact the administrator's ability to troubleshoot the issue.

Reboots as a result of ASRs are always a symptom of the root cause, not the root cause itself. Incidentally, both HP and VMware engineers indicate that they troubleshoot ASR reboots by disabling it, thereby allowing them to gather diagnostic data the next time the crash occurs.

For more information on disabling the ASR feature, see the HP documentation or contact HP support.

Related Information

ESX 环境中的 HP Automatic Server Recovery (ASR)

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware ESX Server

Related Versions:

VMware ESX Server 3.5.x

VMware ESX Server 3.0.x

VMware ESX Server 2.5.x

VMware ESX Server 2.1.x

VMware ESX Server 2.0.x

VMware ESX Server 1.x

VMware ESX Server 1.5.x

VMware ESX 4.1.x

VMware ESX 4.0.x

view all

Take Our Survey

Copyright © 2024 VMware, Inc. All rights reserved.

Terms of Use

Your California Privacy Rights

Privacy

Accessibility

Cookie Settings

Support Assistant