The VMware LAN Segment Name Is a Lie — the pvnID Is the Network

You build a lab in VMware Workstation. Two workstation VMs, each behind its own edge router, each on its own LAN. You attach both to a LAN Segment, give them sensible names, boot them, and one of them cannot reach its gateway. It pulls an APIPA address. There is nothing in any log — not the VM’s, not the router’s — because from every layer’s point of view nothing is wrong. The cable is plugged in. The link is up.

The two VMs are on the same wire, and you did not put them there. The LAN Segment name told you they were separate. The name was lying.

What the interface shows you, and what it hides

In Workstation, a LAN Segment is presented as a named thing. You pick it from a dropdown, it has a label, and two adapters with the same label look like they are on the same network. That label is the entire mental model the interface gives you.

The label is not the network. The network is a 16-byte identifier called the pvnID, stored in each VM’s .vmx file, and it is the only thing that actually decides which adapters share a broadcast domain. The name in the dropdown is a convenience string. The pvnID is the wire.

You cannot see the pvnID in the interface. You can only see it by reading the .vmx.

Reading the real topology

Here is the network identity of a five-VM lab, pulled straight from the .vmx files rather than the interface. Each line is an adapter: its connection type, and — for LAN Segment adapters — the pvnID that defines its network.

===== CHR-TRANSIT =====
ethernet0.connectionType = "nat"
ethernet1.connectionType = "pvn"
ethernet1.pvnID = "52 4d 54 4c 41 42 00 01-a1 b2 c3 d4 e5 f6 07 08"
ethernet2.connectionType = "hostonly"
===== CHR-HQ-EDGE =====
ethernet0.connectionType = "pvn"
ethernet0.pvnID = "52 4d 54 4c 41 42 00 01-a1 b2 c3 d4 e5 f6 07 08"
ethernet1.connectionType = "pvn"
ethernet1.pvnID = "52 4d 54 4c 41 42 00 02-a1 b2 c3 d4 e5 f6 07 08"
ethernet2.connectionType = "hostonly"
===== CHR-BR1-EDGE =====
ethernet0.connectionType = "pvn"
ethernet0.pvnID = "52 4d 54 4c 41 42 00 01-a1 b2 c3 d4 e5 f6 07 08"
ethernet1.connectionType = "pvn"
ethernet1.pvnID = "52 4d 54 4c 41 42 00 03-a1 b2 c3 d4 e5 f6 07 08"
ethernet2.connectionType = "hostonly"
===== CHR-HQ-WS =====
ethernet0.connectionType = "pvn"
ethernet0.pvnID = "52 4d 54 4c 41 42 00 02-a1 b2 c3 d4 e5 f6 07 08"
===== CHR-BR1-WS =====
ethernet0.connectionType = "pvn"
ethernet0.pvnID = "52 4d 54 4c 41 42 00 03-a1 b2 c3 d4 e5 f6 07 08"

Read the pvnIDs, not the VM names. Fifteen of the sixteen bytes are identical across every adapter — 52 4d 54 4c 41 42 (which happens to spell RMTLAB in ASCII, a label the lab’s author chose) and the trailing a1 b2 c3 d4 e5 f6 07 08. Only byte 8 changes: 00 01, 00 02, 00 03.

That one byte is the entire network. Group the adapters by it:

• 00 01 — transit-01 eth1, hq-edge eth0, br1-edge eth0. The transit segment: both edge routers and the core, one broadcast domain.
• 00 02 — hq-edge eth1 and hq-ws eth0. The HQ LAN.
• 00 03 — br1-edge eth1 and br1-ws eth0. The BR1 LAN.

The topology is correct here. Every VM is on the wire it should be. But notice what is carrying that correctness: a single byte, buried sixteen bytes deep in a config file, that no screen in Workstation will ever display.

Where it goes wrong

Look at hq-ws and br1-ws. They are the same kind of thing — a workstation behind an edge router on a LAN — and the only difference between their network attachment is 00 02 versus 00 03.

The obvious way to build the second one is to clone the first. Right-click hq-ws, clone, rename it br1-ws, done. Except a clone inherits the source’s .vmx, and that includes ethernet0.pvnID = "...00 02...". Your new br1-ws boots attached to the HQ LAN, not BR1. If you named both LAN Segments something generic — lan, or internal — the dropdown shows br1-ws on a segment called lan, which is exactly what you expected to see, and nothing looks wrong.

What actually happens: br1-ws sends a DHCP discover, and it is answered by hq-edge’s DHCP server, because that is the router on the 00 02 segment. br1-ws gets a 10.10.10.x address from the HQ pool. Its real gateway, br1-edge, is on 00 03 and never hears it. Depending on pool state you either get a wrong-subnet lease or, if HQ’s pool is exhausted or filtered, an APIPA 169.254.x.x address and no gateway at all.

Every layer reports success. The link is up. The DHCP exchange completed — with the wrong server. There is no error to log, because from the protocol’s point of view nothing failed. You are simply on a different network than the label claimed.

How to catch it

Do not trust the dropdown. Read the pvnID. On Windows, the connection type and pvnID of every VM in a lab directory come out in one pass:

for %V in (VM1 VM2 VM3) do @echo === %V === & findstr /i "pvnID connectionType" "C:\path\%V\%V.vmx"

Group the output by pvnID, not by VM name or segment label. Two adapters share a network if and only if their pvnIDs match, byte for byte. If two VMs you expect on separate LANs show the same pvnID, that is the bug, and it is the only place the bug is visible.

The fix is to give the misplaced adapter the correct pvnID. You can change the LAN Segment in the interface — which rewrites the pvnID underneath — or edit the .vmx directly with the VM powered off. Either way, verify by re-reading the pvnID, not by re-reading the name.

The pattern, again

This site keeps arriving at the same shape from different directions. A RouterOS export shows what was decided, not what is running. A failed import reports a line number, not a state. And a VMware LAN Segment shows you a name you chose, not the network identity that actually moves the packets.

In each case the interface hands you a label that stands in for the truth, and the label and the truth are allowed to disagree. The only reliable move is to read the thing the system actually acts on — the running config, the object list, the pvnID — rather than the human-friendly summary laid over the top of it.

Verified on VMware Workstation 17.5.2, reading the .vmx files of a running five-VM lab. pvnID format and storage are Workstation implementation details and may differ across major versions; the principle — that the segment name is not the network — holds regardless of how the identifier is stored.