To be able to use the Distributed Power Management feature, the motherboard and the NIC used as an uplink for the VMotion network on each of your servers must support wake-on-LAN. Your system and network must also be configured properly.
Most modern machines have the necessary support for wake-on-LAN on the motherboard and PCI bus. In rare cases, this support might be missing or have bugs, so it is important to test a machine's wake-on-LAN capability before relying on it. If you encounter failures, check whether the machine's BIOS setup screens have any options relating to wake-on-LAN, and enable them if so. Normally, if a machine supports wake-on-LAN, ESX/ESXi can enable it through software regardless of the BIOS settings, but try to enable the BIOS settings if they exist. In rare cases this might be required.
A majority of NICs support wake-on-LAN, but there are many that do not. Generally, the NIC device drivers in ESX/ESXi can detect which NIC models support wake-on-LAN. An ESX/ESXi host reports this information to vCenter Server, and if the host's VMotion NIC reports that it does not support wake-on-LAN, the Distributed Power Management feature does not power off the host. It is possible that a NIC's driver claims wake-on-LAN support but it does not work due to a bug, so testing is important. (VMware is not currently aware of any such bugs in NIC drivers.)
Some NICs support wake-on-LAN only at 10 or 100 Mbit/sec, not at 1 Gbit/sec. If such a NIC is connected to an Ethernet switch that supports 1 Gbit (or higher), it will attempt to negotiate down to 100 Mbit/sec when the machine powers off. Therefore, you must ensure that the switch port is set to autonegotiate, not to a fixed 1 Gbit/sec or higher rate. Otherwise the NIC loses its connection to the switch when the machine powers off and wake-on-LAN fails. In rare cases, autonegotiation might not work, due to incompatibility between the switch port and NIC. If this occurs, try a different type of NIC or switch, or use a fixed 100 Mbit/sec rate.
ESX/ESXi encapsulates wake-on-LAN frames in UDP directed broadcast packets. Thus, they are routable in theory, but in practice most routers are configured by default to drop directed broadcast packets that are received from a different subnet. Therefore, your VMotion network should be configured as a single IP subnet, not broken into multiple subnets connected by routers.
Due to the wide variety of available machines and NICs, VMware cannot attempt to test all machines or NICs. This article lists a few of the machines and NICs that have been tested internally. Because manufacturers sometimes keep the same marketing name for hardware despite changing its design, your results might vary.
Machines
We have successfully tested wake-on-LAN on machines of the following machine types:
Our wake-on-LAN tests failed on HP ProLiant DL360 G4 due to a hardware issue that causes most NICs to reset and lose their state when this machine switches them from main to auxiliary power.
The HP ProLiant DL585 supports wake-on-LAN only when using the embedded NIC on its motherboard. Also, you must enable wake-on-LAN from the machine's BIOS setup screen before it will work. Wake-on-LAN does not work at all using NICs plugged into the expansion PCI slots on this platform, because the platform does not supply auxiliary power to these slots.
The Sun Fire 4100M2 does not support wake-on-LAN.
NICs
There are many types of NIC on the market. These can be broadly classified according to the driver they use in ESX/ESXi. However, each driver supports NICs based on several different chipsets, and many of the chipsets appear on NICs made by several different OEMs. Both the chipset and the OEM implementation must support wake-on-LAN so that the NIC supports it. The following table lists chipset and driver combinations and whether or not they support wake-on-LAN.
Chipset vendor | Driver | Supports WOL |
Intel | e100 | Yes |
Intel | e1000 | Yes |
Intel | igb | Yes |
Broadcom | tg3 | Yes |
Broadcom | bnx2 | Yes |
Emulex | be2net | No |
nVidia | forcedeth | Yes |
Neterion | s2io | No |
NetXen | unm_nic | No |
For all the supported chipset and driver combinations above, there still can be individual chipsets or implementations that do not support wake-on-LAN. Also, on some multiport NICs, all ports might not support wake-on-LAN.
The following table lists NICs on which we have successfully tested wake-on-LAN on the port(s) that support it. This list of NICs is organized by PCI ID and the name that ESX/ESXi determines for a NIC by looking at its PCI ID. Manufacturers, however, are free to use the same PCI ID for different NICs that work with the same driver. The name that ESX/ESXi uses for a NIC might not be the same as the marketing name the manufacturer uses. In most cases the name refers to the chipset that the NIC is based on, and not the specific OEM implementation.
Driver | PCI ID | Name |
e100 | 8086:1229 | Intel Corporation 82557/8/9 [Ethernet Pro 100] |
e1000 | 8086:100e | Intel Corporation 82540EM Gigabit Ethernet Controller |
e1000 | 8086:1079 | Intel Corporation 8254NXX Gigabit Ethernet Controller |
tg3 | 14e4:1645 | Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet |
tg3 | 14e4:1648 | Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet |
tg3 | 14e4:1659 | Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet |
tg3 | 14e4:16a7 | Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet |
tg3 | 14e4:16c7 | Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet |
bnx2 | 14e4:164a | Broadcom Corporation NetXtreme II 5706 Gigabit Ethernet |
bnx2 | 14e4:16ac | Broadcom Corporation NetXtreme II BCM5708 1000Base-SX (revision B2 or later) |
forcedeth | 10de:0057 | nVidia NForce Network Controller |
Additional Information
For translated versions of this article, see: