Unable to vMotion to a recently prepped host in a NSX cluster during upgrade to VCF 9.0.0 or 9.0.1
search cancel

Unable to vMotion to a recently prepped host in a NSX cluster during upgrade to VCF 9.0.0 or 9.0.1

book

Article ID: 421863

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • vMotions may fail to an NSX prepped host transport node with the vCenter vMotion wizard reporting a compatibility error of "vdl2: down":

    Currently connected network interface 'Network adapter 1' uses network 'DVSwitch[## ## ## ## ## ## ## ## ## ## ## NSX port group [dvportgroup-####](vdl2 down)', which is not accessible.

  • vdl2 status can be confirmed down on the ESXi host:

    net-dvs -l | grep status.component.vdl2
                    com.vmware.common.opaqueDvs.status.component.vdl2 = down ,        propType = RUNTIME

  • The upgrade to VCF 9.0.0/9.0.1 is currently in progress.

  • While the NSX Managers and some ESX or Edge nodes have been successfully upgraded to NSX 9.0.0/9.0.1, a new ESX Transport Node with lower version is installed/added to the NSX cluster.

  • Following log lines can be seen in /var/log/cloudnet/nsx-ccp.log:

    2025-12-09T16:34:07.066Z  INFO nsx-rpc:CCP-########-####-####-####-############:user-executor-1 StreamingAdapter 3597 - [nsx@4413 comp="nsx-controller" level="INFO" subcomp="nestdb-pigeon"] ########-####-####-####-############: Call status for id 3 is Status(code=INVALID_ARGUMENT, msg=Unrecognized object type 1: 242). Disconnecting...

Environment

VCF 9.0.0 - 9.0.1

Cause

During NSX upgrade to 9.0.0/9.0.1, a new transport node installation (lower host version) while hosts upgrade are still in progress, can result in faulty installation.

Resolution

The issue is fixed in VCF 9.0.2 and 9.1.0.

Workaround 1:
Remove the affected ESXi, finish the host upgrade, then add the host back into NSX after the upgrade is complete.

Workaround 2:
Add a dummy ContainerMsg in NestDb by running the following commands:

opt/vmware/nsx-nestdb/bin/nestdb-cli --json --beautify

put vmware.nsx.nestdb.ContainerMsg {"id" : "00000000-0000-0000-0000-000000000000"}

Restart nsx-proxy service using the following command:

/etc/init.d/nsx-proxy restart

vdl2 should be up now and vmotioning VMs to the affected host should work.

Note: Rebooting the host before finishing the upgrade will cause the issue to come back as reboot wipes out everything in NestDb. Workaround will need to be reapplied.