- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- ESXi host cannot initiate vMotion due to HP-AMS 50...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-13-2014 07:32 AM
11-13-2014 07:32 AM
ESXi host cannot initiate vMotion due to HP-AMS 500.9.6.0
Joe was looking to help a customer regarding the "Agentless Management Service":
************
Dear Experts,
My customer ESXi hosts cannot initiate vMotion due to running version HP-AMS 500.x, they plan on upgrading to AMS version 10.0.1 which will fix the problem, but that upgrade will be pushed out maybe one month down the road as it is part of a full SPP upgrade maintenance.
My question is regarding the workaround mentioned in the vmware knowledge base, if the customer removes the HP-AMS service on their ESXi hosts as a stop gap measure what features will they lose or new risks they may be creating for themselves by performing the vmware workaround mentioned below?
Work Around
To work around this issue, remove the package on all hosts running on one of the preceding AMS versions.
To remove the package on all hosts running on these AMS versions:
- Log in to the host using SSH. For more information, see Using ESXi Shell in ESXi 5.x (2004746).
- Run this command to stop the HP service (does not persist on reboot): /etc/init.d/hp-ams.sh stop
- Run this command to remove the VIB: esxcli software vib remove -n hp-ams
- Reboot the host
*************
Help from John:
Unless something has changed recently, Vsphere HP bits are “dual stack” – meaning that they have a traditional CIM provider agent on there *AND* they have the AMS “service.”
If they dump the AMS, they would still have the CIM provider – which means that the vcenter plugin will still work – and if it was in HP SIM, you’d still get an ILO to Hypervisor association built and could subscribe to WBEM alerts and such.
Joe got additional help:
I got an answer to my original question:
“if the customer removes the HP-AMS service on their ESXi hosts as a stop gap measure what features will they lose or new risks they may be creating for themselves by performing the VMware workaround mentioned below”
Below is a grid that shows the alerting features with and without the AMS Agent.
I’ve also paste the source AMS whitepaper thank you Joe Guydish for providing me this information.
***********
Other comments?