Field level validation errors: {requests[] upgrade_units []... has exceeded its maximum valid length 255 characters}

Products

• VMware NSX

Issue/Introduction

Issue 1: During NSX-T maintenance mode upgrade, there can be an intermediate period where ESX management interface vmk0 receives traffic from VLANs that is different from the VLAN configured in its port group. This issue can occur only during the upgrade process and should be resolved by the time upgrade finishes. 

Issue 2: During NSX-T maintenance mode upgrade, there can be an intermediate period where ESX management interface vmk0 traffic configured with non-zero VLAN in its port group, can go out of ESX untagged 
 

The following error may be observed in the NSX-T UI when performing NSX upgrade on hosts: "request metadata value exceeded its maximum valid length 255 characters"

The following error(s) may be observed in host's vmkernel.log

/var/log/vmkernel.log
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000a for iocl is not ready for new lock model
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000a for iocl is not ready for new lock model
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000b for iocl is not ready for new lock model
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000b for iocl is not ready for new lock model
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000c for iocl is not ready for new lock model
2024-11-17T05:49:04.663Z In(182) vmkernel: cpu58:23619227)NetIOChain: 163: Failed to insert IOChain to port 0x400000c for iocl is not ready for new lock model

 

Environment

VMware NSX (4.1.x, 4.2.0, 4.2.1)

VMware NSX-T  (3.2.x)

Cause

This is caused due to the VLAN IO chains that are needed for switch tagging is not getting inserted properly in the stub-vswitch implementation. As a result, the traffic from vmk0 will not be tagged with VLAN when it leaves the ESX host. And also there is no VLAN forward policy enforcement today in stub-vswitch. This is causing unwanted traffic to be received on the ESX host vmknics during upgrade.

Resolution

FixedInVersion#: 4.2.2 & 9.0

Two workarounds:
1. Perform an "In-place" upgrade

(or)

2. To resolve the field level validation errors:

     a) please check all the hosts in each upgrade group and verify that there are no SLAAC IPv6 addresses, if its present as shown below and not used in the environment, then you can disable the IPv6 router advertisement as shown in the following images:

(Disabling the IPv6 Router advertisement)

   b) then verify that this validation error is resolved by disabling/enabling the Include for Upgrade toggle button on the upgrade group section of the Host upgrades:

  c) If the error is resolved, the Include for Upgrade toggle correctly works, if not it will throw the error. 

  d) Once there is no more error, you can have the Include for Upgrade as Yes and continue the same steps above for rest of the groups and then continue the host upgrades

  f) Once all the upgrades are completed, you can enable the IPv6 router advertisement back on vmk0 of the hosts that were disabled