check-circle-line exclamation-circle-line close-line

VMware Cloud Foundation 3.5.1 Release Notes

VMware Cloud Foundation 3.5.1 | 07 FEBRUARY 2019 | Build 12051558

VMware Cloud Foundation is a unified SDDC platform that brings together VMware vSphere, vSAN, NSX and optionally, vRealize Suite components, into a natively integrated stack to deliver enterprise-ready cloud infrastructure for the private and public cloud. The Cloud Foundation 3.5.1 release continues to expand on the SDDC automation, VMware SDDC stack, and the partner ecosystem.

NOTE: VMware Cloud Foundation 3.5.1 must be installed as a new deployment or upgraded from Cloud Foundation 3.5. For more information, see Installation and Upgrade Information below.

What's in the Release Notes

The release notes cover the following topics:

What's New

The VMware Cloud Foundation 3.5.1 release includes the following:

  • Fibre Channel (FC) Storage Option for Workload Domains -  Enables the addition of the FC datastores as ancillary storage to the Virtual Infrastructure (VI) workload domains. The FC storage must be managed independently from the workload domain vCenter instance. VMware Cloud Foundation supports any FC SAN array which is supported by VMware vSphere. Check with your storage vendor for further information.

  • Multi-Cluster NSX-T Support - Enables deployment of multiple clusters in a NSX-T based Workload Domain.

  • Custom ISO Support for Lifecyle Management - Enables customer-specified ISOs in place of VMware stock images for ESXi upgrades.

  • Miscellaneous Bug Fixes - Includes multiple bug fixes from the Cloud Foundation 3.5 release.

Cloud Foundation Bill of Materials (BOM)

The Cloud Foundation software product is comprised of the following software Bill-of-Materials (BOM). The components in the BOM are interoperable and compatible.

Software Component Version Date Build Number
Cloud Foundation Builder VM 3.5.1 13 DEC 2018 12051558
SDDC Manager 3.5.1 07 FEB 2019 12051558
VMware vCenter Server Appliance 6.7 U1 12 OCT 2018 10244745
VMware Platform Services Controller 6.7 U1 12 OCT 2018 10244745
VMware vSphere (ESXi) 6.7 EP5 09 NOV 2018 10764712
VMware vSAN 6.7 EP5 09 NOV 2018 10764712
VMware NSX Data Center for vSphere 6.4.4 08 DEC 2018 11197766
VMware NSX-T Data Center 2.3.1 14 DEC 2018 11294271
VMware vRealize Suite Lifecycle Manager 2.0 20 SEP 2018 10150522
VMware vRealize Log Insight 4.7 04 OCT 2018 9983377
vRealize Log Insight Content Pack for NSX for vSphere 3.8 n/a n/a
vRealize Log Insight Content Pack for Linux 1.0 n/a n/a
vRealize Log Insight Content Pack for vRealize Automation 7.3+ 2.1 n/a n/a
vRealize Log Insight Content Pack for vRealize Orchestrator 7.0.1+ 2.0 n/a n/a
vRealize Log insight Content Pack for NSX-T 3.1 n/a n/a
VMware vRealize Operations 7.0 24 SEP 2018 10098133
VMware vRealize Automation 7.5 20 SEP 2018 10053539


  • vRealize Log Insight Content Pack for vRealize Automation is installed during the deployment of vRealize Automation.
  • vRealize Log Insight Content Pack for vRealize Orchestrator is installed during the deployment of vRealize Automation.
  • vRealize Log Insight Content Pack for NSX-T is installed alongside the deployment of the first NSX-T workload domain.
  • VMware Solution Exchange and the vRealize Log Insight in-product marketplace store only the latest versions of the content packs for vRealize Log Insight. The software components table contains the latest versions of the packs that were available and automation at the time VMware Cloud Foundation released. When you deploy the VMware Cloud Foundation components, it is possible that the version of a content pack within the in-product marketplace for vRealize Log Insight is newer than the one used for this release.

VMware Software Edition License Information

The SDDC Manager software is licensed under the Cloud Foundation license. As part of this product, the SDDC Manager software deploys specific VMware software products.

The following VMware software components deployed by SDDC Manager are licensed under the Cloud Foundation license:

  • VMware ESXi
  • VMware vSAN
  • VMware NSX Data Center for vSphere

The following VMware software components deployed by SDDC Manager are licensed separately:

  • VMware vCenter Server
    NOTE Only one vCenter Server license is required for all vCenter Servers deployed in a Cloud Foundation system.
  • VMware vRealize Automation
  • VMware vRealize Operations
  • VMware vRealize Log Insight and content packs
    NOTE Cloud Foundation permits limited use of vRealize Log Insight for the management domain without purchasing full vRealize Log Insight licenses.

For details about the specific VMware software editions that are licensed under the licenses you have purchased, see the Cloud Foundation Bill of Materials (BOM) section above.

For more general information, see the VMware Cloud Foundation.

Supported Hardware

For details on vSAN ReadyNodes in Cloud Foundation, see the VMware Compatibility Guide (VCG) for vSAN and the Hardware Requirements section in the VMware Cloud Foundation Planning and Preparation Guide.


To access the Cloud Foundation 3.5.1 documentation, go to the VMware Cloud Foundation product documentation.

To access the documentation for VMware software products that SDDC Manager can deploy, see the product documentation and use the drop-down menus on the page to choose the appropriate version:

Browser Compatibility and Screen Resolutions

The Cloud Foundation web-based interface supports the following web browsers:

  • Google Chrome: Version 70.x or 69.x
  • Internet Explorer: Version 11
  • Mozilla Firefox: Version 63.x or 62.x

For the Web-based user interfaces, the supported standard resolution is 1024 by 768 pixels. For best results, use a screen resolution within these tested resolutions:

  • 1024 by 768 pixels (standard)
  • 1366 by 768 pixels
  • 1280 by 1024 pixels
  • 1680 by 1050 pixels

Resolutions below 1024 by 768, such as 640 by 960 or 480 by 800, are not supported.

Installation and Upgrade Information

You can install Cloud Foundation 3.5.1 as a new release or upgrade from Cloud Foundation 3.5.

In addition to these Release Notes, see the VMware Cloud Foundation Operations and Administration Guide for information about the upgrade process.

Installing as a New Release

The new installation process has three phases:

Phase One: Prepare the Environment

The VMware Cloud Foundation Planning and Preparation Guide provides detailed information about the software, tools, and external services that are required to implement a Software-Defined Data Center (SDDC) with VMware Cloud Foundation, using a standard architecture model.

Phase Two: Image all servers with ESXi

Image all servers with ESXi 6.7 U1 and update to ESXi 6.7 EP5 (build 10764712). See Knowledge Base article 58715 Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation for details. See also the VMware Cloud Foundation Architecture and Deployment Guide for information on installing ESXi.

Phase Three: Install Cloud Foundation 3.5.1

Refer to the VMware Cloud Foundation Architecture and Deployment Guide for information on deploying Cloud Foundation.

Upgrade to Cloud Foundation 3.5.1

You can upgrade to Cloud Foundation 3.5.1 only from 3.5. If you are at a version earlier than 3.5, refer to the 3.5 Release Notes for information on how to upgrade to 3.5.

See Knowledge Base Article 67416 for details on the upgrade to NSX Manager 6.4.4. 

For information on upgrading to 3.5.1, refer to the VMware Cloud Foundation Operations and Administration Guide.


Resolved Issues

  • Password management blocked after failed password rotation.

    When password rotation fails, there is no Cancel or Retry option in the interface. As a consequence, password management is blocked.

    Fixed in this release. (3.5.1)

  • NSX-T workload domain creation: running task shows incorrect progress message.

    After triggering an NSX-T workload creation workflow, if you expand the task status, the Deploy vCenter subtask shows a status of "Failed to deploy vCenter" even though the process is still running. This status is incorrect. The subtask and workflow will complete successfully.

    Fixed in this release. (3.5.1)

  • vSAN SSD capacity disks marked as ineligible

    When running pre-bringup Audit Validation, an error displays because the audit shows the capacity to be under a terabyte, which is the recommended minimum capacity disk size.

    Fixed in this release. (3.5.1)

  • vRealize Suite: The IaaS ManagerService stops running on the IaaS manager service nodes after certificate replacement.

    After replacing the certificate for the vRealize Automation resource, the Manager Service stops running on the IaaS manager service nodes. This can be observed by accessing the vRealize Automation appliance and opening the vRealize Automation Settings tab. Expand the IaaS manager service entries (for example, iaasms1.<serviceusername>.local or iaasms2.<serviceusername>.local) and the ManagerService shows a status of Stopped.

    Fixed in this release. (3.5.1)

  • IP address for the load balancer VM shows as N/A in the SDDC Manager interface.

    In the Services tab in the MGMT domain page shows N/A as the IP address for the vRealize Log Insight load balancer VM.

    Fixed in this release. (3.5.1)

  • NFS datastore creation may fail in workload domain creation.

    When creating an NFS-based workload domain or cluster, the system does not validate the NFS server and mount configuration input. As a result, if incorrect information has been input, the workload domain creation workflow will accept the input anyway. This results in workload domain creation failure.

    Fixed in this release. (3.5.1)

  • Licensing page is missing several columns of data.

    Observed in Internet Explorer browser. The Licensing page displays only the Product Name. All other data columns are not displayed.

    Fixed in this release. (3.5.1)

  • After deleting all the NSX-T workload domains, any new NSX-T workload domain creation workflow fails.

    This results from the deletion of the NSX-T Manager and NSX Controller nodes from the inventory even though the corresponding appliances persist in the management cluster.

    Fixed in this release. (3.5.1)

  • Cancel Network validation causes Host Validation to fail on next validation run.

    If you try to cancel validation while the Network Connectivity validation task is running, on the next validation, the Host Validation operation will fail with physical NIC issues, such as Physical NIC vmnic1 is connected to adt_vSwitch_01 on esxi host esxi-1 ( should be disconnected.

    Fixed in this release. (3.5.1)

  • Upgrade process returns invalid data error.

    Observed when upgrading from 3.0 to 3.0.1, and from 3.0.1 to 3.5. When upgrading through the Lifecycle Manager, the system returns this error: Scheduling immediate update of bundle failed. UPGRADE_SPEC_INVALID_DATA; User Input cannot be null/empty, User Input is required for this upgrade.

    Fixed in this release. (3.5.1)

  • Multiple NSX-T workload domains cause conflicting overlay transport zones.

    If you create more than one NSX-T workload domain, each subsequent domain has a separate set of overlay networks. As a result, the different NSX-T edges cannot communicate because that requires a single overlay transport zone.

    Fixed in this release. (3.5.1)

  • Bulk password rotation results in inaccurate failed message.

    If you select numerous domains for password rotation, the operation succeeds (as shown in the Tasks panel) but the Password Management page displays a Failed to rotate... 504 Gateway Time-out message.

    Fixed in this release. (3.5.1)

  • During bringup, platform audit returns vSAN Connectivity Validation errors.

    Observed in a deployment configuration containing six 1TB HDDs and two SSD caches of about 370GB. This suggests that the vSAN platform audit may not be robust enough to handle this excessive number of devices; however, the values in the error message are incorrect and bringup can continue to successful completion.

    Fixed in this release. (3.5.1)

  • Workload domain creation not blocked by missing install bundles.

    This issue has been observed in 3.5 deployments shortly after upgrade. The user tries to create a workload domain before all install bundles have completed downloading. This condition of missing bundle should prevent the user from proceeding. However, the only warning of a problem comes when the user tries to add a new host to the new workload domain.

    Fixed in this release. (3.5.1)

  • Unable to filter download bundles by status.

    Observed only in the Internet Explorer browser. When viewing download bundles in the SDDC Manager, the feature for filtering by status does not function.

    Fixed in this release. (3.5.1)

  • ADD HOST SPEC operation does not accept vmnicToVdsNameMap data.

    Observed by service providers whose environments requires two distributed switches. For example, they may place Management and VXLAN on one network fabric, and vSAN and vMotion on another. As a result, there may be instances where the first hosts in the cluster will use different vmnics than additional hosts, requiring the user to map the vmnics in the newly added server to the correct distributed switch.

    Fixed in this release. (3.5.1)

  • Unable to download or print current validation report.

    After cancelling a validation, you can only download or print the most recent successful validation report, as opposed to the current one.

    Fixed in this release. (3.5.1)

  • The Configure CA workflow fails if the Microsoft CA password contains certain special characters.

    The Configure CA workflow fails if the Microsoft CA password contains the following special characters:  < > (left or right angle brackets), ' (single quote or apostrophe), " (double quote), or & (ampersand). To mitigate risk from persistent cross-site scripting, SDDC Manager converts these characters to Unicode, replacing them with escape characters, thus making the password invalid.

    Fixed in this release. (3.5.1)

  • Host cleanup feature is supported only for hosts commissioned on the MGMT VLAN.

    The new Supportability and Serviceability (SoS) utility option (--cleanup-host) only functions on hosts commissioned on the MGMT VLAN, and not on hosts on other VLANs.

    Fixed in this release. (3.5.1)

Known Issues

The known issues are grouped as follows.

Bringup Known Issues
  • Clicking the Help icon in the Bring-up wizard opens the help for an older release.

    The Help icon in the Bring-up wizard links to the product help for an older version.

    Workaround: To open the help topic on deploying Cloud Foundation, perform the following steps:

    1. In a browser window, navigate to

    2. Click Browse All Products and then click VMware Cloud Foundation.

    3. Click VMware Cloud Foundation Architecture and Deployment Guide.

    4. In the left navigation pane, click Deploying Cloud Foundation.

  • Cloud Foundation Builder fails to initiate with "[Admin/Root] password does not meet standards" message

    When configuring the Cloud Foundation Builder admin and root passwords, format restrictions are not validated. As a result, a user may create a password that does not comply with the restrictions. As a result, Cloud Foundation Builder will fail upon initiation.

    Workaround: When configuring Cloud Foundation Builder, ensure that the password meets the following restrictions:

    • Minimum eight characters long.
    • Must include both uppercase and lowercase letters
    • Must include digits and special characters
    • Must not include common dictionary words
  • Bringup process fails at task Disable TLS 1.0 on vRealize Log Insight Nodes

    The Bringup fails at the task Disable TLS 1.0 on vRealize Log Insight Nodes with the following error Connect to [/] failed: Connection refused (Connection refused). This issue has been observed on slow environments after restarting a vRealize Log Insight node. The node does not start correctly and its API is not reachable.

    Workaround: Use the following procedure to work around this issue.

    1. Restart the failed Bringup execution in the Cloud Foundation Builder VM and open the bringup logs.
      This will retry the failed the Bringup task, which might still fail on the initial attempt. The log shows an unsuccessful connection to the LogInsight node.
    2. While Bringup is still running, use SSH to log in to the Log Insight node that is shown as failed in the Bringup log.
    3. Run the following command to determine the connection issue.
      loginsight-node-2:~ # service loginsight status
      It should confirm that the daemon is not running.
    4. Execute the following command:
      loginsight-node-2:~ # mv /storage/core/loginsight/cidata/cassandra/data/system ~/cassandra_keyspace_files
    5. Reboot the Log Insight node.
    6. Confirm that it is running.
      loginsight-node-2:~ # uptime
      18:25pm up 0:02, 1 user, load average: 3.16, 1.07, 0.39
      loginsight-node-2:~ # service loginsight status
      Log Insight is running.

    In a few minutes, the Bringup process should successfully establish a connection to the LogInsight node and proceed.

  • Bringup and VI workload domain workflows fail at VM deployments if any hosts are in maintenance mode

    Neither operation checks for host maintenance mode state. As a result, NSX controller deployments fail. This is expected because vSAN default policy requires a minimum of three ESXi nodes to be available for deployment.

    Workaround: If you encounter this error, do the following:

    1. Through either vCenter or the esxcli utility, take the affected hosts out of maintenance mode:
      esxcli system maintenanceMode set -e 0
    2. Restart the failed workflow.
  • Cloud Foundation Builder VM remains locked after more than 15 minutes.

    The VMware Imaging Appliance (VIA) locks out the user after three unsuccessful login attempts. Normally, the lockout is reset after fifteen minutes but the underlying Cloud Foundation Builder VM does not automatically reset.

    Workaround: Using SSH, log in as admin to the Cloud Foundation Builder VM, then switch to root user. Unlock the account by resetting the password of the admin user with the following command.
    pam_tally2 --user=<user> --reset

  • Unable to cancel JSON Spec Validations.

    This is observed during the Bringup process when there is an error in the JSON file. The user is unable to cancel the JSON validation, but it might take up to five minutes if there's no connectivity to the ESXi hosts

    Workaround: There is no workaround to enable the desired cancellation. However, if this occurs, after the validation fails, review the JSON for syntax or other errors. Correct these errors and try again.

  • During bring-up, the vRealize Log Insight API fails intermittently with a license error.

    During bring-up, the vRealize Log Insight API fails intermittently with a license error while configuring content packs. with the following message:
    Error while installing content packs to Log Insight: Failed post request in vRLI ...

    Workaround: Manually verify that the correct license key is successfully added to vRealize Log Insight and retry the workflow. If this doesn’t work, then add the content pack through the VRLI UI and retry the workflow.

  • Validation fails on SDDC Manager license.

    During the bringup process, the validation for the SDDC Manager license fails.

    Workaround: Enter a blank license and proceed. You can enter the correct license value later in the process.

  • During bring-up, the component sheet incorrectly lists the wrong NSX version.

    During the bring-up process, detailed information of the components to be deployed are displayed. This display incorrectly shows NSX version 6.4.3 but this is incorrect. The actual version being deployed is NSX 6.4.4.

  • Cloud Foundation Builder: Restart of imaging service fails.

    During the host imaging operation, the imaging service (imaging.service) fails when restarted.

    Workaround: If you encounter this issue, perform the following procedure:

    1. Stop the imaging service in the SDDC Manager VM.
      systemctl stop imaging.service
    2. Stop all processes related to imaging.
      ps - ef | grep imag
      kill <process_number>
    3. Sleep the system for five seconds.
      sleep 5
    4. Start the imaging service.
      systemctl start imaging.service
      It should restart correctly.
  • Platform audit validation fails on network connectivity validation.


    The network connectivity validation fails as expected when there are no free vmnics on one of the hosts. But the test port group cleanup does not happen on all hosts after this failure. The residual port group entries are causing the network connectivity to fail and if hosts are not cleaned up, it could result in the bringup failure .

    Workaround: If you encounter this issue, use the following procedure:

    1. Complete the host cleanup procedure on the problem hosts with the port group issues (clean up the test port groups on the vmnic).

    2. Retry the platform audit validation.
      You may need to repeat this step until all hosts are identified and cleaned up.

    3. Verify that hosts have no persisting test port groups.

    4. Retry validation.
      It should succeed if all problem hosts have been cleaned up.

Upgrade Known Issues
  • Operations against an existing NSX-T workload domain fails after upgrading VMware Cloud Foundation to version 3.5.1

    Operations against an existing NSX-T workload domain fails on the "Gather input to add host to NSX-T Fabric and migrate networking from dvs to nvds" task.  These operations can include creating a new cluster, expanding a cluster or removing a host from a cluster.

    Workaround: See Knowledge Base article 67030.

  • Operationsmanager component fails to come up after RPM upgrade.

    After manually upgrading the operations manager RPM to the latest version, the operationsmanager fails to come up. The system returns INFO-level message: Waiting for changelog lock... This is likely caused by overlapping restarts of the service preventing any from succeeding. This can happen to any service (e.g. ) which is exercising liquibase, such as commonsvcs.

    Workaround: Clean the databasechangeloglock table from the database.

    1. Log in to the SDDC Manager VM as admin user "vcf".
    2. Enter su to switch to root user.
    3. Run the following commands:
      1. In the postgres command prompt, open the password manager to delete the database change log lock:
        # psql -h /home/postgresql/ -U postgres -d password_manager -c "delete from databasechangeloglock"
      2. Restart the operationsmanager component:
        # systemctl restart operationsmanager
      3. Verify the operationsmanager is running:
        # curl http://localhost/operationsmanager/about
        It should return something like:
        "","description":"Operations Manager"}
  • Some component upgrades fail due to disabled NTP servers.

    Observed when upgrading from 3.0.x to 3.5. The Platform Service Controller and vCenter Server component updates fail because they are unable to ping the disabled NTP server. The NTP server may be unavailable during the upgrade.

    Workaround: Before upgrading, reconfigure the Platform Service Controller and vCenter Server components to synchronize with the ESXi hosts. After the upgrade, you can restore the previous configuration to synchronize with the NTP server. See Configure the System Time Zone and Time Synchronization Settings in the vSphere documentation for details.

  • The upgrade process to version 3.5 may leave some hosts using previous ESXi version.

    The Lifecycle Manager by default displays only the latest ESXi version based on the bill of materials. However, with workload domains running on two ESXi versions, errors may result.

    Workaround: Manually update the ESXi version on all hosts.

  • During upgrade from 3.0.1 to 3.5, user is not notified of required vRealize Suite Lifecycle Manager upgrade.

    After upgrading from Cloud Foundation 3.0.1 to 3.5, you must upgrade vRealize Suite Lifecycle Manager from 1.2 to 2.0 before deploying vRealize Suite components in the upgraded version. Without this upgrade, vRealize Suite components will fail to deploy.

    Workaround: If the user has already deployed vRealize Suite Lifecycle Manager in a previous Cloud Foundation deployment, update this component prior to deploying any vRealize components in Cloud Foundation 3.5. Otherwise, the deployment may fail.

  • Cloud Foundation 3.5 to 3.5.1 upgrade: operations manager upgrade fails at SERVICE UPGRADE INITIATION phase.

    The likely cause of this error is the presence of failed host commission workflows. To upgrade successfully, there can be no such failed worklfows.

    Workaround: Before starting the upgrade process from 3.5 to 3.5.1, check your deployment for any failed host commission workflows and resolve them.

vRealize Integration Known Issues
  • vRealize Operations in vRealize Log Insight configuration fails when vRealize Operations appliances are in a different subdomain

    During vRealize Suite deployment in Cloud Foundation, the user provides FQDN values for vRealize load balancers. If these FQDNs are in a different domain than the one used during initial bringup, the deployment may fail.

    Workaround: To resolve this failure, you must add the vRealize Operations domain to the configuration in the vRealize Log Insight VMs.

    1. Log in to the first vRealize Log Insight VM.
    2. Open the /etc/resolv.conf file in a text editor, and locate the following lines:
      domain vrack.vsphere.local
      search vrack.vsphere.local vsphere.local 
    3. Add the domain used for vRealize Operations to the last line above.
    4. Repeat on each vRealize Log Insight VM.
  • vRealize Suite Lifecycle Manager is not properly cleaned-up during uninstall.

    vRealize Suite Lifecycle Manager is not cleaned-up during an uninstall of a failed vRealize Automation or vRealize Operations Manager deployment. This may happen if the deployment workflow for vRealize Automation or vRealize Operations fails under some specific conditions on step “ChangeVrslcmPasswords”. For example, if SDDC Manager services are restarted during this operation. As a result, vRealize Suite Lifecycle Manager VM is not be properly cleaned up from the system during the uninstall process of the failed vRealize Automation or vRealize Operations Manager deployment.

    Consecutive attempts to deploy vRealize Automation or vRealize Operations Manager will fail due to vRealize Suite Lifecycle Manager being left in a bad state.

    Workaround: Follow the steps outlined in Knowledge Base article 57917 to fix the issue.

  • SoS network cleanup utility fails on the hosts in two VDS switch configuration.

    This utility is not supported in a two VDS switch configuration in the current release.

  • Certificate replacement for the vRealize Automation component fails with 401 error

    Certificate replacement for the vRealize Automation component fails due to a 401 unauthorized error with the message "Importing certificate failed for VRA Cafe nodes." This issue is caused by a password lockout in the vRealize Automation product interface. For example, independently of Cloud Foundation, a user tried to log in to vRealize Automation with the wrong credentials too many times, causing the lockout.

    Workaround: The lockout period lasts for thirty minutes, after which the certification replacement process can succeed.

  • vRealize Automation integration fails with NSX-T workload domain.

    NSX-T does not yet support vRealize Automation integration.

    Workaround: None.

  • Upgrade to vRealize Suite Lifecycle Manager 2.0 removes Environments Cards and Request History

    The upgrade process from vRealize Suite Lifecycle Manager 1.2 to 2.0 replaces the deployed appliance and restores a baseline configuration. This action subsequently removes any previous environment cards from the user interface and the request history. This may create auditing concerns; however, the originating requests for vRealize Suite product actions (such as deployment, workload domain connections, and so on) are maintained in the SDDC Manager logs.

    Workaround: Verify that vRealize Log Insight is manually configured for log retention and archiving. This will help to ensure that the SDDC Manager logs with the historical and originating vRealize Suite product action requests are preserved. For example, see Configure Log Retention and Archiving for vRealize Log Insight in Region A in the VMware Validated Design 4.3 documentation.

  • vRealize Log Insight node is configured with syslog server IP address.

    Observed after deploying Cloud Foundation and creating an NSX-T workload domain. When you enable Log Insight for the NSX-T workload domain, the active Log Insight is inadvertently configured as one of the syslog server node's IP addresses, instead of the load balancer virtual appliance IP address.

    Workaround: Using SSH, log in as admin user to the NSX-T Manager and NSX-T controller nodes to manually modify the configuration to point to the load balancer virtual appliance as syslog server. Perform the following procedure on each node:

    1. List the current syslog server IP address and port configuration:
      get logging-server
    2. Modify to the desired IP address:
      set logging-server <load balancer IP address:port> proto udp level info
    3. Confirm by listing the configuration information again:
      get logging-server
Networking Known Issues
  • Platform audit for network connectivity validation fails

    The vSwitch MTU is set to the same MTU as the VXLAN VTEP MTU. However, if the vSAN and vMotion MTU are set to 9000, then vmkping fails.

    Workaround: Modify the nsxSpecs settings in the bring-up JSON by setting the VXLANMtu as a jumbo MTU because vSwitch is set with the VXLAN MTU value. This will prevent the error seen in the platform audit.

  • NSX Manager is not visible in the vSphere Web Client.

    In addition to NSX Manager not being visible in the vSphere Web Client, the following error message displays in the NSX Home screen: "No NSX Managers available. Verify current user has role assigned on NSX Manager." This issue occurs when vCenter Server and the permission is not correctly configured for the account that is logged in.

    Workaround: To resolve this issue, follow the procedure detailed in Knowledge Base article 2080740 "No NSX Managers available" error in the vSphere Web Client.

  • After password rotation of the NSX-T workload domain, Add Host operation fails.

    After rotating the vCenter and ESXi passwords of the NSX-T workload domain, the Add Host operation fails. Specifically, the sub-task that configures the fabric fails. This appears related to the password rotation, but the cause is that the NSX-T host is insufficiently prepared and thus fails.

    Workaround: Log in to NSX-T Manager, remove the failed host, and retry the Add Host operation in SDDC Manager.

  • The PSC and VC update fails if the ping to the NTP servers is disabled.

    The VC upgrade cannot check the NTP time with the server.

    Have the NTP server without any security and ensure that it works correctly on the standard NTP port.

SDDC Manager Known Issues
  • Add Cluster task fails due to non-case-sensitive cluster naming.

    The Add Cluster task fails due to a UUID error if you create a new cluster with the same name even though the case may be different. For example, this task would fail if you tried to add "Cluster1" if "cluster1" already exists.

    Workaround: When naming clusters in the Add Cluster task, verify that the name is unique.

  • The host status keeps showing "Deactivating" even though the REMOVE HOSTS task fails in the SDDC Manager tasks list.

    The attempt to remove a dead host results in state for that host to be stuck in the deactivating state. This prevents the removal of this host from the cluster through removal by force also, thereby preventing further workflows to go through as well.

    Workaround: If you encounter this issue, use the following procedure:

    1. Run the following curl command and note down the ID of the dead host.

      ​curl http://localhost/inventory/hosts | json_pp

    2. Run the following curl command to update the status of the host in inventory to ERROR.

      curl -X PATCH http://localhost/inventory/entities/{id} -H'Content-type: application/json' -H'Accept: application/json' -d @host_status.json

      Note that the {id} needs to be replaced with the one obtained in the previous step. And the content of  host_status.json is as follows:


      "status" : ERROR",

      "type": ESXI"


    3. Attach the vmnic of dead host freed-up during the failed attempt, back to N-VDS (Attach vmnic0 to uplink1)
    4. Trigger host removal with force option checked.

    This issue is seen only for the NSX-T workload domains.


Workload Domain Known Issues
  • The vSAN HCL database does not update as part of workload domain creation

    When you create a workload domain, the vSAN HCL database should update as part of the process. As a result, database moves into a CRITICAL state, as observed from vCenter.

    Workaround: Manually update the vSAN HCL database as described in Knowledge Base article 2145116.

  • Adding host fails when host is in a different VLAN

    This operation should succeed as adding a host to workload domain cluster should succeed even though the new host is on a different VLAN than other hosts in the same cluster.


    1. Before attempting to add a host, add a new portgroup to the VDS for the cluster.
    2. Tag the new portgroup with the VLAN ID of the host to be added.
    3. Run the Add Host workflow in the SDDC Manager Dashboard.
      This will fail at the "Migrate host vmknics to dvs" operation.
    4. Locate the failed host in vCenter, and migrate the vmk0 of the host to the new portgroup you created in step 1.
      For more information, see Migrate VMkernel Adapters to a vSphere Distributed Switch in the vSphere product documentation.
    5. Retry the Add Host operation.
      It should succeed.

    NOTE: If you remove the host in the future, remember to manually remove the portgroup, too, if it is not used by any other hosts.

  • In some cases, VI workload domain NSX Manager does not appear in vCenter.

    Observed in NFS-based workload domains. Although VI workload domain creation was successful, the NSX Manager VM is not registered in vCenter and as a result, not appearing in vCenter.

    Workaround: To resolve this issue, use the following procedure:

    1. Log in to NSX Manager (http://<nsxmanager IP>).
    2. Navigate to Manage > NSX Management Service.
    3. Un-register the lookup service and vCenter, then re-register.
    4. Close the browser and log in to vCenter.
  • Unable to delete VI workload domain enabled for vRealize Operations Manager from SDDC Manager.

    Attempts to delete the vCenter adapter also fail, and return an SSL error.

    Workaround: Use the following procedure to resolve this issue.

    1. Create a vCenter adapter instance in vRealize Operations Manager, as described in Configure a vCenter Adapter Instance in vRealize Operations Manager.
      This step is required because the existing adapter was deleted by the failed workload domain deletion.
    2. Follow the procedure described in Knowledge Base article 56946.
    3. Restart the failed VI workload domain deletion workflow from the SDDC Manager interface.
  • Adding cluster to a NSX-T workload domain fails with the error message "Invalid parameter: {0}".

    If you try to add cluster to a NSX-T workload domain and it fails with the error message "Invalid parameter: {0}", the subtask that creates logical switches has failed. This is likely due to an issue where artifacts from previously removed workload domains and clusters are conflicting with the new switch creation process.

    Workaround: Delete the hosts from the NSX-T Manager if exists and then delete the stale logical switches. the logical switches are created in the following pattern:

     ls-<UUID>-management, ls-<UUID>-vsan, ls-<UUID>-vmotion

    For all these three logical switches, {UUID} remains the same. For these logical switches, the logical ports are shown as "0" (ZERO).  The user has to delete these logical switches.

  • Workload domain operations may fail due to licensing issue

    Workload domain operations (such adding a host, cluster, or workload domain) may fail at the task "Apply License(s) to ESXi Host in vCenter Server" with the error "License application through vCenter failed". The problem is that your deployment has exhausted its available ESXi license keys.

    Workaround: In addition to adding new license keys, you must perform the following clean-up procedure:

    1. Delete the currently failed workflow domain.
    2. Clean up all affected hosts.
    3. Decommission and recommission the hosts.

    You can now add the valid license keys and re-initiate the failed operation with the newly added license key.

  • Unable to delete cluster from any NSX workload domain.

    The likely cause of this error is the presence of a dead or deactivated host within the cluster. To resolve this, you edit the workflow entry to remove reference to the offending host.

    Workaround: To resolve this issue, perform the following procedure.

    1. In SDDC Manager (Inventory > Workload Domains > [workload domain] > [cluster]), try to delete the cluster in order to identify the problematic host.
    2. Using SSH, log in to the SDDC Manager VM to obtain the workflow ID.
      Run curl -s http://localhost:7200/domainmanager/workflows to return a JSON listing all workflows.
    3. Using the workflow ID, get the workflow input.
      curl -s http://localhost:7200/domainmanager/internal/vault/<workflow-id> \
      -XGET > remove_cluster_input.json
    4. Edit the remove_cluster_input.json file by removing the entry referencing the problematic host.
      1. Find the reference to the host under the heading:
      2. Delete the entire entry for the problematic host.
      3. Save the edited file as remove_cluster_input_deadhost_removed.json.
    5. Update the workflow with the new file.
      curl -s http://localhost:7200/domainmanager/internal/vault/<workflow-id> -XGET > \
      -XPUT -H "Content-type: text/plain" -d @ remove_cluster_input_deadhost_removed.json
    6. Return to SDDC Manager and retry the workflow.
      It will fail at the logical switches deletion task.
    7. In NSX Manager, clear the host as follows:
      1. Go to NSX > Nodes > Transport Nodes and delete the same host as a transport node.
      2. Go to NSX > Nodes > Hosts and delete the same host.
    8. Return to SDDC Manager and restart the workflow.
      It should succeed.
  • If the first NSX-T workload domain creation fails, subsequent NSX-T workload domain creations fail also.

    If the first NSX-T workload creation fails for any reason, subsequent NSX-T workload domain creation workflows will fail also with the error: Failed to fetch NSX-T configuration. HTTP failure response... To resolve, you must clear the initial failed workflow. This is by design because the failed workload domain impacts the NSX Manager node.

    Workaround: Before you can create additional NSX-T workload domains, you must either repair the failed workflow or delete the failed workload domain completely from the inventory. You can then create a new one.

  • NSX-T workload domain: Adding a cluster with NFS storage fails.

    This issue has been sometimes observed when, after removing all NSX-T workload domains, the user creates a new NSX-T workload and adds a cluster with NFS storage. The cause is an undiagnosed validation error.

    Workaround: None.

  • Removal of a dead host from the NSX-T workload domain fails and subsequently, the removal of the workload domain fails

    In some cases where the creation of NSX-T workload domain fails, the subsequent attempt to delete the dead hosts fails as well. The host is disconnected from vCenter. Therefore manual intervention is required to connect back. This issue is also seen when the domain is created successfully but then one of the host goes dead.

    If a host removal operation fails, since the host is dead (i.e host is disconnected from VC), then perform the following steps:

    1. Log in to NSX-T Manager.
    2. Identify the dead host under fabric->nodes->transport nodes.
    3. Edit the transport node and select the N-VDS tab.
    4. Under Physical NICs, assign vmnic0 to the uplink.
    5. From SDDC Manager, retry the failed domain deletion task.


  • If there is a dead host in the cluster, the subsequent task of adding a cluster or a host fails.

    If one of the hosts of the workload domain goes dead and the user tries to remove the host, the task fails. And then, that particular host is set to the deactivating state without providing an option to forcefully remove it.

    Bring the dead host back to normal state, after which the add-cluster and add-host tasks succeed.

Security Operations Known Issues
  • Updating password policy failure results in UPDATE message when should be FAILED

    If the password policy fails, the system shows an UPDATE status and the transaction history shows the message "Operation failed in 'appliance update', for  credential update." In actuality, the operation has FAILED because the new password does meet requirements. A more appropriate message would read "Password update has failed due to unmet policy requirements" and recommend reviewing the policy.

    Workaround: Review the password policy for the component in question and modify the password configuration as necessary, and try again to update.

  • SSL Certificate Replacement for vCenter breaks vRealize Operations data collection

    After replacing the certificate for the vCenter Server component, both the vCenter and vSAN components in vRealize Operations Manager report a "Collection failed" error message. Testing the connection and attempting to accept the new certificate returns additional error messages: Unable to establish a valid connection to the target system. Adapter instance has been configured to trust multiple certificates, when only one is allowed. Please remove any old, unneeded certificates and try again.

    Workaround: If you encounter this issue, use the following procedure to resolve the situation.

    1. Delete the current vCenter and vSAN adapters.
    2. Re-create them using the same configuration and credentials originally set by vRealize Operations.
    3. Test the connection, accept the new certificates, and save the configuration.
  • vRealize Operations Manager admin password fails after a successful password rotation or update.

    After rotating or updating the vRealize Operations Manager admin password in Cloud Foundation, the new password may fail when trying to log in to the vRealize Operations Manager dashboard. Specifically, if you obtain the modified password using the password lookup utility, and use that password to log in to vRealize Operations Manager, it may fail.

    Workaround: Update the vRealize Operations Manager password directly to match the password modified in Cloud Foundation.

    1. From Cloud Foundation, use the SoS lookup-password utility to obtain the modified password.
    2. Using SSH, log in to the vRealize Operations Manager master node.
    3. Run the following command:
      $VMWARE_PYTHON_BIN $VCOPS_BASE/../vmware-vcopssuite/utilities/sliceConfiguration/bin/ --reset
    4. When prompted for a password, provide the one obtained in step 1.
    5. If this fails, retry or cancel.
      If you cancel, rotate the password again in Cloud Foundation.
Known Issues Affecting Service Providers
  • Domain manager workflows fail when using SDDC Manager to manage an API-created cluster or domain.

    If you have a cluster or domain that was created through the API, and you try to manage it through the SDDC Manager dashboard, the workflow will fail. This affects the following domain manager workflows: Add/Remove Host, Add/Remove VI Workload Domain, and Add/Remove Cluster.

    Workaround: None. Clean up the failed workflow and try again using the API.