...
A vSphere 4.x host participating in a Distributed Resource Scheduler (DRS) cluster while configured to use Distributed Power Management (DPM) fails to enter Standby mode. You receive the error:vCenter has determined that is cannot resume host HostName from standby; therefore, the enter standby task was stopped. Confirm that IPMI/ILO is correctly configured for host HostName. Or, configure vCenter to use Wake-On-LAN, ensuring that there are at least two or more hosts in the cluster, and try the task again. The Enter standby mode task fails with the status:The operation is not supported on the object. The vCenter Server logs contain a message similar to:[VpxdMoHost] Can't wake-up host HostName, so not putting it into standby mode.
The VMware Distributed Power Management (DPM) feature allows a DRS cluster to reduce its power consumption by powering hosts on and off based on cluster resource utilization. If excess capacity is present in the cluster, DPM places one or more hosts in standby mode, migrates their virtual machines to other hosts, and powers them off. If vCenter Server cannot reliably power a host back on, it does not allow the host to enter standby mode.
DPM can use one of these three power management protocols to bring a host out of standby mode: Intelligent Platform Management (IPMI) Hewlett-Packard Integrated Lights-Out (iLO) Wake-On-LAN (WOL). Prior to placing an ESX/ESXi host in Standby mode with DPM, vCenter Server check to ensure that it can reliably reach the host using the configured method. If a host supports multiple protocols, they are evaluated and used in the order: IPMI, iLO, WOL. Consult the Testing section specific to the configured method. If the vCenter Server determines that the host can be reliably powered back on from standby mode, it attempts to put the host in standby. If this task fails, consult the Failure to enter Standby mode section below. Testing whether DPM Power On using IPMI or iLO is suitable The vCenter Server is provided with addresses and credentials for a hardware Baseboard Management Controller (BMC) for the managed server. To exit standby mode, vCenter Server will authenticate to the BMC and initiate power-on of the server hardware. Prior to entering standby, vCenter Server confirms that it can connect to the configured BMC with the provided credentials. If connection or authentication fail, the host is not placed in standby mode. For more information on the requirements for using IPMI or iLO, see the Configure IPMI or iLO Settings for VMware DPM section of the vSphere Resource Management Guide for your version of vSphere 4.x. Failure to reach the reach the hardware Baseboard Management Controller (BMC) will be logged by the vCenter Server. For more information, see Location of vCenter Server log files (1021804). If IPMI or iLO information is provided, but is not valid, vCenter Server logs the message:[IsIpmiInfoValidInt] Host HostName: a field is null or over-sized. If valid IPMI or iLO information is provided, but the BMC is not reachable, vCenter Server logs the message:[VpxdMoHost] Despite valid IpmiInfo for HostName, SendIpmiMessageInt failed. Testing whether DPM Power On using Wake-On-LAN is suitable The vCenter Server uses Wake-On-LAN network packets to bring another host out of standby. To exit standby mode, vCenter Server connects to a currently-active host in the same Cluster as the target, and request that host to send Wake-On-LAN packets to the target host. Prior to entering standby, vCenter Server confirms that the target host is capable of receiving WOL packets, and that it is managing a peer ESX/ESXi host which is capable of sending the WOL packets. For more information on the requirements for using Wake-On-LAN, see the Test Wake-on-LAN for VMware DPM section of the vSphere Resource Management Guide for your version of vSphere 4.x. vCenter Server evaluates the target host to determine whether it is capable of receiving WOL packets. If the target host cannot receive WOL packets, the reason is logged by the vCenter Server and the host is not placed in standby mode. For more information, see Location of vCenter Server log files (1021804). WOL packets are sent and received on the VMotion network interface. If the target host does not have a VMotion network interface, vCenter Server logs the message:[VpxdMoHost] Vmotion Vnic info for host HostName is not available If the target host has a VMotion network interface which is missing an IP address or Subnet mask, vCenter Server logs the message:[VpxdMoHost] Bad Vmotion IP ( IPAddress) or subnet mask ( SubnetMask) for HostName. If the target host has a VMotion network interface using a third-party Distributed Virtual Switch, all physical uplinks for that switch must support WOL. If one of the uplink interfaces does not support WOL, vCenter Server logs the message:[VpxdMoHost] DVS Host HostName has a non-WoL-capable NIC InterfaceName. If the target host has a VMotion network interface using a standard vSwitch or VMware Distributed Virtual Switch, at least one of the physical uplinks for that switch must support WOL. If none of the uplink interfaces support WOL, vCenter Server logs the message:[VpxdMoHost] Host HostName doesn't have any WoL-capable NICs. vCenter Server enumerates all hosts in the same cluster as the target, and attempts to locate a suitable peer host for sending Wale-On-LAN packets to the target host. If given hosts are unsuitable, a reason is logged by the vCenter Server. If none of the hosts in the same cluster as the target are suitable for sending WOL packets, the host is not placed in standby mode. For more information, see Location of vCenter Server log files (1021804). If a potential host is unsuitable for sending WOL packets to the target host, vCenter Server logs that the host is unsuitable:[VpxdMoHost] Host PotentialHostName can't be a peer-host for host HostName. A host used for waking up the target host must be connected to and responsive in vCenter Server. If a potential host is not currently connected to vCenter Server (appears Disconnected), vCenter Server logs the message:[VpxdMoHost] Host PotentialHostName isn't connected. A host used for waking up the target host out of standby must not also be in standby. If a potential host is unsuitable is already in Standby mode, vCenter Server logs the message:[VpxdMoHost] Host Potential HostName is in standby mode. A host used for waking up the target host must be capable of sending WOL packets over the network. If a potential host doesn't support sending WOL packets, vCenter Server logs the message:[VpxdMoHost] Host PotentialHostName doesn't support Send-WoL. A host used for waking up the target host must have a VMotion interface with the same subnet mask as the target. If a potential host doesn't have the same VMotion network subnet, vCenter Server logs the message:[VpxdMoHost] Host PotentialHostName isn't in the same Vmotion subnet. A host used for waking up the target host must have a VMotion interface with physical uplink network interfaces enabled. If a potential host doesn't have any physical uplink network interfaces used for VMotion, vCenter Server logs the message:[VpxdMoHost] Host PotentialHostName doesn't have any Vmotion pNics. If no suitable peer ESX/ESXi host can be located in the same Cluster and on the same VMotion network subnet, and which is capable of sending Wake-On-LAN packets, vCenter Server logs the message:[VpxdMoHost] No peer hosts found for host: HostName. Failure to enter Standby mode If the vCenter Server determines that the host can be can be reliably powered back on from standby, it attempts to put the host in standby mode. This operation consists of putting the host in maintenance mode, migrating off any virtual machines, and powering down the host. If the host fails to enter standby mode, vCenter Server logs the message: [VpxdMoHost] Exception happened when host HostName was entering standby mode. To troubleshoot this issue: If entering standby mode times out before 20%, during the "Waiting for all virtual machines to be powered off or migrated" phase, there is a problem with evacuating virtual machines from the host and putting it in maintenance mode. This is a required dependency of entering Standby mode. For more information, see ESX/ESXi host fails to go into maintenance mode (1036167).In this event, vCenter Server may log messages similar to:[VpxdMoHost] Timedout waiting for VM power-off on host HostName.[VpxdMoHost] Evacuation of all powered-off VMs on HostName failed. If entering standby mode times out between 60%-95%, during the "Waiting for host to stop responding" phase, there is a problem powering off the host.In this event, vCenter Server may log messages similar to:[VpxdMoHost] After waiting for NNN secs host HostName didn't power-down." For further assistance determining why a vSphere host is not entering the standby mode, open a support ticket with VMware Support to determine the cause of the failure. Cite this KB article ID 2001651 and any error messages seen. For more information, see Filing a Support Request in Customer Connect (2006985).
Location of vCenter Server log filesESXi/ESX host fails to go into maintenance modeHow to file a Support Request in Customer Connect