VMware NSX Cloud. See What's New for a list of enhancements.
What's in the Release NotesThe release notes cover the following topics:
About VMware NSX Cloud
See: NSX Cloud FAQs
The known issues are grouped as follows.Known Issues in Service Patch 3
- Issue 2045573: You may encounter an error after selecting the PEM file while deploying PCG in CSM.
While deploying a PCG from CSM, you may encounter an error after selecting the PEM file or typing in its name.
Workaround: Refresh the browser window.
- Issue 1951825: The values for "nsx_switch_tag" are missing in the UI
After deploying the PCG, the values for the "nsx_switch_tag" are missing in the UI.
Workaround: If after PCG deployment you don't see values for the nsx_switch_tag in the UI, undeploy and redeploy that PCG.
- Issue 1972351: Redeploy of primary PCG causes certificate mismatch in the NSX agent running on workload VMs.
When the CGW/PCG is undeployed from the CSM, the gateway certificate should be cleaned up from the workload VM. If this is not cleaned up then in the scenario that another instance of the gateway is re-deployed and this instance gets the same IP address as the un-deployed instance then the certificate mismatch error will be seen.
Workaround: Always clear the PCG certificates from workload VMs whenever a PCG (connected to these VMs) is un-deployed. There is an NSX CLI available to do this:
- Log in to the workload VM and type nsxcli. This takes you to the nsxcli command prompt.
- Use either one of the following commands to clear the certificate:
- del gateway certificates: this clears the certificate for both active and standby PCGs.
- del gateway certificate <IP address of the gateway>: if you use this command, specify the IP address of the gateway that was undeployed.
- Issue 1998843: When PCG is in HA mode and the primary gateway goes down, then the status of the standby gateway is inaccurately shown as down.
When you undeploy the active gateway or if it goes down for some reason, the status of the standby gateway is inaccurately shown as down and can be confusing. There is no impact to functionality.
- Issue 2032160: CSM does not recognize the new secondary gateway and it is shown as an unmanaged VM.
When deploying PCG in HA mode, if the secondary PCG fails to deploy at first, but after resolving the reason for failure, is redeployed successfully, it may appear as an unmanaged VM in CSM.
Workaround: Do one of the following:
- Re-sync the AWS account to reflect changes.
- OR restart CSM
- Issue 2004641: Unable to change VPC Quarantine policy when one of the PCGs is down.
If you deploy PCG in HA pair, you are not able to change the Quarantine Policy for the VPC, when one of the gateways is down.
Workaround: Ensure that both the PCGs are up before changing VPC Quarantine policy.
- Issue 2051188: User-defined firewall rule for an NSGroup may not work
In some situations when a DFW rule is applied to an NSGroup, that DFW rule may not take effect.
Workaround: Do the following:
- Recreate the NSGroup.
- Recreate the DFW rule with the new NSGroup.
- Delete the old NSGroup and the DFW rule.
- Issue 2051329: Possible issues with moving Windows VMs between logical switches
If you move a Windows workload VM from one logical switch to another multiple times, it is possible that the VM does not move to the correct logical switch.
Workaround: Do one of the following:
- If you have access to the VM, run the following command in a command prompt: "sc.exe stop nsx-agent" to fix the problem.
- OR reboot the VM through the AWS EC2 console.
- Issue 2040658: RHEL/CentOS Workload VMs in the underlay mode may lose connectivity after the "reboot" command is issued.
When you use the "reboot" command for workload VMs managed by NSX in the underlay mode, all processes shut down, including NSX agent, but upon reboot, SSH connectivity is not restored, as expected. In AWS, the workload VM appears to be active. This issue is observed on CentOS 7.2 and RHEL 7.4.
Workaround: From the AWS console, stop the workload VM. When the VM's state changes to "Stopped" in AWS, start the VM. The VM can be accessed using SSH after this.