Subscribe to my RSS Feed
Join 2,575 other subscribers
My ramblings on the stuff that holds it all together
I encountered this error in my lab recently, I previously wrote about how I was able to use DPM in my home lab, I’ve recently re-built it into a different configuration but found that I was no longer able to use just Wake on LAN (WoL) to put idle cluster hosts into standby.
I got the following error, vCenter has determined that it cannot resume host from standby.
Confirm that IPMI/iLO is correctly configured or, configure vCenter to use Wake-On-LAN.
1st thing to note is that there is nowhere in vCenter to actually configure Wake-on-LAN, however you can check to see which NICs in your system support Wake On LAN (not all do, and not all have WoL-enabled vSphere drivers)
My ML115 G5 host has the following NICs
In my current configuration the onboard NIC is connected to a dvSwitch and is used for the management (vmk) interface
This seems to be the cause of the problem because if I move the vmk interface (management NIC) out of the dvSwitch and configure it to use a normal
dvSwitch vSwitch DPM works correctly.
In a production environment a real iLO/IPMI NIC is the way to go as there are many situations that could make WoL unreliable. However, if you want to use DPM and don’t have a proper iLo you need to rely on Wake-On-LAN so you need to consider the following..
Also, worth noting that if you are attempting to build a vTARDIS with nested ESXi hypervisors you cannot use DPM within any of your nested ESXi nodes, the virtual NICs (e1000) do support WoL with some other guest-types like Windows, so your VM guests can respond to WoL packets (via the following UI screens)
However the e1000 driver that ships with vSphere ESX/ESXi does not seem to implement the WoL functionality so you wont be able to use DPM to put your vESXi guests to sleep – kind of an edge-case bit of functionality and ESX isn’t an officially supported guest OS within vSphere so it’s not that surprising.
Found an error on your post and I have updated below:
This seems to be the cause of the problem because if I move the vmk interface (management NIC) out of the dvSwitch and configure it to use a Standard vSwitch DPM works correctly.