Updated on: 20 Nov 2017
VMware NSX Cloud: See What's New.
Check for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
About VMware NSX Cloud
See: NSX Cloud Documentation.
Frequently Asked Questions
- My NSX Cloud Dashboard reflects the new features, and the documentation lists them, but I don't see any changes in CSM and NSX Manager. What am I missing?
Changes are reflected in CSM and NSX Manager after the upgrade process has completed. The Upgrade and Maintenance tile on the NSX Dashboard displays the upgrade status. When upgrade succeeds, all new features and bug-fixes are available.
- Which browsers are supported in the current release?
The current release supports:
- Google Chrome
- Mozilla Firefox
- How should I invoke REST APIs when using NSX Cloud?
To invoke REST APIs using NSX Cloud, do the following:
- Get Access Token using VMware Cloud APIs. See Generate Access Keys in the VMware Cloud services documentation.
- Pass an additional HTTP header for making NSX-T REST API calls:
- NSX Cloud Dashboard: What should I do if I see the following error while logging in: "error="invalid_grant", error_description="Invalid redirect: https://console.nsx.cloud.vmware.com/nsxaas-dashboard/index.html does not match one of the registered values: [https://console.nsx.cloud.vmware.com/login]"?
If you see this OAUTH error, log in from https://console.nsx.cloud.vmware.com/login.
- Does NSX Cloud support switching to a different organization if I signed up as part of multiple organizations?
Yes. You can switch to a different organization from the NSX Cloud dashboard. If you are not signed up for NSX Cloud through the organization to which you are switching, you will be redirected to the VMware Cloud Services dashboard with a message indicating you do not have access to NSX Cloud. The message is: "You don't have access to Unknown Service Name".
- Is Edge Firewall supported in this release?
Edge is a component of the NSX Public Cloud Gateway (PCG). Edge Firewall is not supported in the current release.
- Are CGW and PCG, both acronyms for the NSX Public Cloud Gateway?
Yes. CGW and PCG are both acronyms for the NSX Public Cloud Gateway.
Here is a list of APIs that have changed in the current release:
|Old Endpoint||New Endpoint|
|GET /csm/aws-regions||GET /csm/aws/regions|
|GET /csm/aws-subnets||GET /csm/aws/subnets|
|GET /csm/aws-accounts||GET /csm/aws/accounts|
|POST /csm/aws-accounts||POST /csm/aws/accounts|
|GET /csm/aws-vpcs||GET /csm/aws/vpcs|
The following properties have been renamed:
- In AwsAccountStatus type definition, inventory_sync_state has been renamed to inventory_sync_step
- In AwsGatewayInstanceStatus type definition, deployment_state has been renamed to deployment_step
- Issue 1901986: View the VM's connection ID in the output of the "get gateway-controller vm-state" command.
The "get gateway-controller vm-state” command, issued on the Public Cloud Gateway’s CLI to get the status of VMs, has been enhanced to display the VM’s connection ID in addition to other details.
- Issue 1931194: Quarantine Policy status now available in List view in addition to Card view.
You can confirm whether Quarantine Policy is enabled or not for a VPC from the List view in addition to Card view, from the CSM dashboard.
- Issue 1941121: Free up the EIP if previously associated, to set up NAT rules using the nsx:publicip tag.
You no longer need to reapply the nsx:publicip tag if you used a previously associated EIP as a value for this tag, causing NAT rule-creation to fail. Disassociating the EIP is all you need to do.
- Issue 1947476: Better error messages if PCG deployment fails.
Enhanced error messages for PCG deployment failure now specify the reason for failure, for example, EIP allocation failure, or missing IGW entry from route tables for management and uplink subnets.
- Issue 1946735: Inventory graphic updated to display more accurate results.
The inventory graphic on NSX Dashboard has been enhanced to display the number of VMs accurately.
The known issues are grouped as follows.General Issues
- Issue 1919024: I tagged my VM correctly and installed the agent but logical switches are not showing up in NSX Manager and my VM is quarantined. What should I do?
If you encounter this problem, try the following:
- Check whether the AWS tag’s value is correctly typed in.
- Refresh the AWS account from CSM.
- Issue 1938326: When I undeploy PCG with downlink and DHCP ports, do all the relevant ports get deleted as well?
No. Before undeploying PCG, make sure that all NSX entities are cleaned up. All VMs should be unmanaged, and you should delete all user-created entities -- logical switches, routers, DHCP servers, firewall rules etc.
- Issue 1933110: What happens when the NSX Public Cloud Gateway (PCG) is deleted or crashes?
If the PCG is deleted or crashes, you cannot recover it. You need to delete all NSX entities associated with the unrecoverable PCG.
Do one of the following:
- From the Cloud Service Manager, undeploy the unrecoverable PCG node.
- From NSX Manager, delete the Fabric node associated with the unrecoverable PCG.
- Issue 1928545: Why does the NSX agent installation on Ubuntu 14.04.05 fail?
If you are trying to install the NSX agent on an instance where ec2-net-utils package is already present, NSX agent installation may fail.
Remove the package ec2-net-utils from the instance and retry installing the NSX agent.
- Issue 1931804: How should I recover when I lose connectivity in the overlay network after changing a VM's connection to a logical switch?
On a Windows VM, use the command:
ipconfig /release <VIF-name>
ipconfig /renew <VIF-name>
On a Linux VM, use the command:
- Issue 1923242: Are IPFIX and mirroring only allowed to a remote VM within the same VPC?
Yes. IPFIX and Port Mirroring are features where local traffic stats or local traffic is sent to a remote VM. NSX Cloud, mandates the remote VM to be in the same VPC in the same VPC subnet/CIDR.
- Issue 1927049: IPFIX in NSX Cloud is only permited on standard port
NSX Cloud functionality sends IPFIX traffic using UDP port 4739. In NSX manager, the user can only configure port 4739 for the IPFIX collector.
- Issue 1930227: What is the recommended way to secure VMs deployed in the underlay mode?
When the nsx:network tag is applied to VMs from AWS, the VMs are moved to vm-underlay-sg security group by NSX. This security group is configured to allow all ingress traffic to these VMs since NSX cannot foresee what underlay services will be accessing the VMs. This, however, makes the underlay VMs insecure if these VMs have public IP.
- Issue 1941917: What happens if nsx:publicip tag is assigned to the VMs when both PCGs in the compute VPC are down?
If nsx:publicip tag is assigned to the VMs when both PCGs in the compute VPC are down, when the PCGs are restored, traffic from the internet to the tagged EIP will not work since PCGs don't configure themselves appropriately to route traffic to that EIP.
Workaround: Tag the VMs with nsx:publicip only after the PCGs are brought back up.
- Issue 1951825: What should I do if I don't see values for nsx_switch_tag in the UI after PCG deployment?
If after PCG deployment you don't see values for the nsx_switch_tag in the UI, undeploy and redeploy that PCG.
- Issue 1953314: What happens if I tag a workload VM with nsx:publicip using an Elastic IP that is already associated with another instance/interface?
The public IP configured using the tag "nsx:publicip" will not be accessible or functional.
Workaround: Do the following:
- From the AWS console, disassociate the Elastic IP from the configured instance/interface
- Remove the "nsx:publicip" tag from the instance/interface
- Wait for 60 seconds for the changes to take effect
- Tag the instance/interface with the "nsx:publicip" associating the EIP that was released in step 1.
- Issue 1865996: How should I recover after a split-brain is healed but causing N-S traffic to be blackholed?
After a split-brain is healed, the AWS gateway may still be using the standby PCG's uplink IP as DNAT, causing N-S traffic to be sent to the wrong service router.
Workaround: Assuming the split brain is healed and now there is only one stable active preferred PCG:
- Manually delete all NAT rules (SNAT and DNAT) from NSX manager.
- Restart the preferred PCG node.
- Make sure only one default SNAT rule is created with the secondary IP pointing to the preferred AWS PCG.