VM Network Adapter Disconnected After a Reboot: Read Its Device State

A virtual machine (VM) comes back from a reboot, a host reboot or a vSphere HA restart, and its network adapter shows as disconnected in the vSphere Client. The quick fix is to tick Connected and move on.

Ticking Connected is a change. It does not tell you why the adapter came up disconnected or whether it will happen again, and the checkbox alone does not show that the guest's network or its applications have recovered. Broadcom documents at least three different causes: a cleared setting, a port the host could not find, and a timing issue on ephemeral port groups. This guide shows how to tell them apart by reading the VM's settings and log. It changes nothing.

This guide is based on source research only. Nothing in it was run. VM, host and port group names below are fictional.

What Broadcom documents

Two settings are involved, and neither one measures connectivity:

• Connected is the virtual device's connection state as observed now.
• Connect at power on is the configured intent for the device's state when the VM starts. KB 436747 and KB 368679 both describe adapters that came up disconnected with it selected, so it is an intent, not a guarantee.

The value you read today may not be the value at the incident start; it can have been changed since. Whether the guest actually reaches the network is a third, separate observation. KB 445427 asks for both settings to be checked on the gateway VM.

Before you start

• Read access to the VM's settings in the vSphere Client (Edit Settings, each Network adapter, Device Status). Open the dialog to read it, then cancel.
• Read access to the VM's vmware.log for the boot in question, through someone with datastore access. Reading it does not change the VM. Log lines name a device such as Ethernet0 (KB 436747); record how that device maps to the adapter in the settings, or record the mapping as unconfirmed.
• The network behind each adapter: a standard switch port group or a distributed port group. Only for a distributed port group, read its port binding (static or ephemeral) from the port group's settings. The vSphere 8.0 page Edit General Distributed Port Group Settings defines static binding as assigning a port "when the virtual machine connects" and ephemeral as "No port binding". For a standard switch, record binding as "not applicable".
• How the VM got to its current state: newly deployed from a template, cloned, restored, registered from the host command line, a hypervisor power-off and power-on (from vCenter or from the host), a guest OS restart only, or an HA restart.
• Records from around that start, if retained: the VM's power-off and power-on tasks, any host sync or reconfigure of the adapter, and any change to the adapter's settings since. Without a dated configuration record from that start, today's checkbox is a current observation only. A missing entry in a task list does not show that the setting was unchanged.

Do not tick Connected, change Connect at power on, power-cycle, re-register or run a network test while you collect this. Each is a change, and power-cycling can destroy the timing evidence for the ephemeral case.

Step 1: record the device state, one record per adapter

On a VM with several adapters, keep a separate record for each. A log line for one device says nothing about another adapter.

If the adapter is missing from the VM's hardware list entirely, this guide does not apply. KB 425783 covers an adapter removed from inside the guest operating system, which is a different case from a disconnected one.

Step 2: match the record

The table is an editorial grouping of the KBs. The static and ephemeral rows apply only to an adapter on a positively identified distributed port group. For a standard switch port group, binding is not applicable, and only the first and last rows and the log apply. For static binding, this guide uses only the KB 436747 log signature and does not explain how vCenter assigns distributed ports.

Worked example (fictional)

fin-app-02 was restored from backup on Thursday afternoon and powered on. It has no network. It has one adapter. The record reads:

Reading it:

• Connect at power on is unchecked now; its value at that start is unknown. A missing reconfigure entry does not show the setting was unchanged. The record is consistent with KB 317134, not confirmed for that start.
• The VM is a restore. KB 413851 says restore operations may clear this option on purpose to avoid IP conflicts.
• The question for the owner is whether the original fin-app-02 is still running on the same network. That is answered first. Selecting Connect at power on, and connecting the adapter, are then separate recorded changes, and network access is confirmed afterwards by its own check, not by the checkbox.

Contrasting record (fictional)

web-07 is restarted after patching. Its only adapter (Ethernet0) is on an ephemeral distributed port group. Connect at power on is checked, Connected is unchecked, and vmware.log has no "failed to connect" line. The VM was not re-registered. The patch record shows a guest OS restart only, and no power-off, power-on, host sync or reconfigure record is available for that start.

KB 368679's sequence needs a power-off, a power-on from the host and a host sync between them, so this record does not establish it. The case stays a candidate with timing evidence missing. Ticking Connected now would change the record, so it is captured first. Any reconnection or reboot is a separate owner decision, not a diagnosed fix.

Troubleshooting

Acceptance checks

1. For each adapter: its identity and log device mapping (or "unconfirmed"), network type, binding (or "not applicable"), Connect at power on and Connected as read now, evidence of the setting at the incident start (or "unknown"), and what happened before the boot are recorded, with the VM, host, versions and observation time.
2. vmware.log for that boot was read for "will start disconnected" and "failed to connect" for that adapter's device.
3. Each adapter is matched to one row in Step 2, marked as a candidate where the row's evidence is missing, or marked as not explained.
4. For a restored or cloned VM, the owner confirmed the original is not on the same network before reconnecting.
5. No adapter, VM power state, registration or network setting was changed while collecting the record.
6. Any later reconnection is handed on as a separate change, and network recovery is confirmed by its own check, not by a checkbox.

Risk notes

• Connecting a restored or cloned copy can create a duplicate IP or MAC address on the network. KB 413851 explains that clearing Connect at power on can be deliberate for this reason.
• Re-registering a VM is a change to inventory. KB 436747 says to do it through vCenter, as a planned change.
• Rebooting the VM is an outage for that VM. It is KB 368679's resolution for a matching case, not a diagnostic step.
• A gateway VM's adapter state affects every VM behind it. KB 445427 shows how one disconnected adapter looks like a multi-VLAN outage.

These are source-documented behaviours. Expert review and a lab check are still needed before any change to a vSphere environment.

Learning notes

• Connected is the observed device state; Connect at power on is the configured intent for a start. Neither one measures whether the guest reaches the network.
• An unchecked Connect at power on explains a disconnected start only if it was unchecked at that start.
• Template deployments, clones and restores may leave the option unchecked on purpose.
• If the option is checked on a distributed port group, the binding and this adapter's log lines can point to a missing distributed port. The ephemeral host-sync case needs timing records; without them it stays a candidate.
• Keep one record per adapter. When many VMs lose their gateway at once, read each of the gateway VM's adapters first; the symptom alone does not prove the cause.

References

Related articles

• Duplicate IP or MAC address after a VM clone or restore, for what to check before a copy is connected.
• Static IP lost after a VM restore or virtual NIC change, for the guest side once the adapter is connected.