This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware Cloud Foundation 5.1.1 | 26 MAR 2024 | Build 23480823

Check for additions and updates to these release notes.

What's New

The VMware Cloud Foundation (VCF) 5.1.1 release includes the following:

Deprecation Notices

  • VMware End Of Availability of Perpetual Licensing and SaaS Services. See https://blogs.vmware.com/cloud-foundation/2024/01/22/vmware-end-of-availability-of-perpetual-licensing-and-saas-services/ for more information.

  • The VMware Imaging Appliance (VIA), included with the VMware Cloud Builder appliance to image ESXi servers, is deprecated and removed.

  • Starting with VMware Cloud Foundation 5.1, Configuration Drift Bundles are no longer needed as part of the upgrade process and are now deprecated.

  • The Composable Infrastructure feature is deprecated in VMware Cloud Foundation 5.1 and will be removed in a future release.

  • In a future release, the "Connect Workload Domains" option from the VMware Aria Operations card located in SDDC Manager > Administration > Aria Suite section will be removed and related VCF Public API options will be deprecated.

    Starting with VMware Aria Operations 8.10, functionality for connecting VCF Workload Domains to VMware Aria Operations is available directly from the UI. Users are encouraged to use this method within the VMware Aria Operations UI for connecting VCF workload domains, even if the integration was originally set up using SDDC Manager.

VMware Cloud Foundation Bill of Materials (BOM)

The VMware 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 Builder VM

5.1.1

26 MAR 2024

23480823

SDDC Manager

5.1.1

26 MAR 2024

23480823

VMware vCenter Server Appliance

8.0 Update 2b

29 FEB 2024

23319993

VMware ESXi

8.0 Update 2b

29 FEB 2024

23305546

VMware vSAN Witness Appliance

8.0 Update 2

21 SEP 2023

22443122

VMware NSX

4.1.2.3

12 MAR 2024

23382408

VMware Aria Suite Lifecycle

8.16

29 FEB 2024

23377566

  • VMware vSAN is included in the VMware ESXi bundle.

  • You can use VMware Aria Suite Lifecycle to deploy VMware Aria Automation, VMware Aria Operations, VMware Aria Operations for Logs, and Workspace ONE Access. VMware Aria Suite Lifecycle determines which versions of these products are compatible and only allows you to install/upgrade to supported versions.

  • VMware Aria Operations for Logs content packs are installed when you deploy VMware Aria Operations for Logs.

  • The VMware Aria Operations management pack is installed when you deploy VMware Aria Operations.

  • You can access the latest versions of the content packs for VMware Aria Operations for Logs from the VMware Solution Exchange and the VMware Aria Operations for Logs in-product marketplace store.

Supported Hardware

For details on supported configurations, see the VMware Compatibility Guide (VCG) and the Hardware Requirements section on the Prerequisite Checklist tab in the Planning and Preparation Workbook.

Documentation

To access the Cloud Foundation 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 VMware Cloud Foundation web-based interface supports the latest two versions of the following web browsers:

  • Google Chrome

  • Mozilla Firefox

  • Microsoft Edge

For the Web-based user interfaces, the supported standard resolution is 1920 by 1080 pixels.

Installation and Upgrade Information

You can install VMware Cloud Foundation 5.1.1 as a new release or perform a sequential or skip-level upgrade to VMware Cloud Foundation 5.1.1.

Installing as a New Release

The new installation process has three phases:

  • Phase One: Prepare the Environment: The Planning and Preparation Workbook 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 the ESXi version mentioned in the Cloud Foundation Bill of Materials (BOM) section. See the VMware Cloud Foundation Deployment Guide for information on installing ESXi.

  • Phase Three: Install Cloud Foundation 5.1.1: See the VMware Cloud Foundation Deployment Guide for information on deploying Cloud Foundation.

Upgrading to Cloud Foundation 5.1.1

You can perform a sequential or skip-level upgrade to VMware Cloud Foundation 5.1.1 from VMware Cloud Foundation 4.4.x or later. If your environment is at a version earlier than 4.4.x, you must upgrade the management domain and all VI workload domains to VMware Cloud Foundation 4.5.x or above and then upgrade to VMware Cloud Foundation 5.1.1. For more information see VMware Cloud Foundation Lifecycle Management.

Important:

Before you upgrade a vCenter Server, take a file-based backup. See Manually Back Up vCenter Server.

Note:

Since VMware Cloud Foundation disables the SSH service by default, scripts that rely on SSH being enabled on ESXi hosts will not work after upgrading to VMware Cloud Foundation 5.1.1. Update your scripts to account for this new behavior. See KB 86230 for information about enabling and disabling the SSH service on ESXi hosts.

Resolved Issues

The following issue is resolved in this release:

  • Creating Sub Transport Node Profile (TNP) per cluster does not enforce maximum limit.

  • All NSX Edge clusters and host clusters are upgraded, even when you choose to upgrade a subset of clusters.

  • Cosmetic issue: References to NSX+ in SDDC UI.

  • The SDDC Manager UI shows that the VMware Aria Suite Lifecycle 8.12 install bundle is required, instead of the VMware Aria Suite Lifecycle 8.14 bundle.

  • Creating or validating a new cluster with the VMware Cloud Foundation API fails if the cluster name contains more than 20 characters. For VMware Cloud Foundation 5.1.1, a cluster name can contain between 1and 80 characters when it is created using the VMware Cloud Foundation API.

  • When creating a workload domain with vVol storage and the smart NIC feature enabled, hosts are not visible in the host selection data grid.

  • Incorrect warning is shown in UI during Create Domain/Add Cluster using Static IP Pool.

  • Edge node uplink information is blank during expansion.

  • Password rotation for Platform Services Controller (PSC) fails with error: Unable to connect to entity : VRLI.

  • When networkProfileName is empty string, Add Host fails.

  • An API for NSX Clusters is listed on VMware Cloud Foundation Developer Center in error.

Known Issues

VMware Cloud Foundation Known Issues

  • Lifecycle Management Precheck does not throw an error when NSX Manager inventory is out of sync

    The Lifecycle Management Precheck displays a green status and does not generate any errors for NSX Manager inventory.

    Workaround: None

  • Upgrade Pre-Check Scope dropdown may contain additional entries

    When performing Upgrade Prechecks through SDDC Manager UI and selecting a target VCF version, the Pre-Check Scope dropdown may contain more selectable entries than necessary. SDDC Manager may appear as an entry more than once. It also may be included as a selectable component for VI domains, although it's a component of the management domain.

    Workaround: None. The issue is visual with no functional impact.

  • Converting clusters from vSphere Lifecycle Manager baselines to vSphere Lifecycle Manager images is not supported.

    vSphere Lifecycle Manager baselines (previously known as vSphere Update Manager or VUM) are deprecated in vSphere 8.0, but continue to be supported. See KB article 89519 for more information.

    VMware Cloud Foundation 5.0 does not support converting clusters from vSphere Lifecycle Manager baselines to vSphere Lifecycle Manager images. This capability will be supported in a future release.

    Workaround: None

  • Workload Management does not support NSX Data Center Federation

    You cannot deploy Workload Management (vSphere with Tanzu) to a workload domain when that workload domain's NSX Data Center instance is participating in an NSX Data Center Federation.

    Workaround: None.

  • Stretched clusters and Workload Management

    You cannot stretch a cluster on which Workload Management is deployed.

    None.

Upgrade Known Issues

  • New - Compatibility warning when upgrading VCF 5.1 to 5.1.1

    A warning may appear in the SDDC Manager UI when planning an upgrade from VMware Cloud Foundation 5.1 to VMware Cloud Foundation 5.1.1.

    Workaround: The upgrade path from 5.1 to 5.1.1 is fully supported, so this warning can be ignored.

  • Workspace ONE Access inventory sync fails in SDDC Manager after upgrading VMware Aria Suite Lifecycle

    After upgrading Aria Suite Lifecycle to version 8.12 or later, triggering a Workspace ONE Access inventory sync from Aria Suite Lifecycle fails. The SDDC Manager UI reports the following error: Failed to configure WSA <wsa_fqdn> in vROps .vrops_fqdn>, because Failed to manage vROps adapter.

    Workaround: Download the bundle for your version of Aria Suite Lifecycle to SDDC Manager and retry the inventory sync.

  • Upgrading to vCenter Server 8.0 Update 2b fails

    In some circumstances, upgrading to vCenter Server 8.0 Update 2b may fail with the error 'vpxd:Expand' failed.

    Workaround: See KB 96830.

  • Aria Suite Lifecycle root account status is "disconnected" after upgrading to VMware Aria Suite Lifecycle 8.16

    When you upgrade to Aria Suite Lifecycle 8.16 from a version earlier than 8.14, the host keys in SDDC Manager do not get updated. As a result, SDDC Manager cannot connect to Aria Suite Lifecycle and you cannot manage the passwords or certificates for Aria Suite Lifecycle.

    Workaround: Contact VMware by Broadcom Support to update the host keys for Aria Suite Lifecycle.

  • VCF ESXi Upgrade with 'quick boot' option fails for hosts configured with TPM.

    After performing an upgrade, the host is stuck during quick boot in PSOD with A security violation was detected.

    Workaround: Rebooting the host will complete the upgrade.

  • When you upgrade SDDC Manager, the SDDC Manager UI does not redirect to the upgrade status screen

    When the SDDC Manager upgrade moves to IN PROGRESS, the UI hangs and does not display the upgrade status.

    NOTE: This issue does not affect 5.1 to 5.1.1 upgrades.

    Workaround: Refresh the browser to see the current upgrade status.

  • The FINISH button in the ESXi Upgrade UI allows multiple clicks and upgrades to be initiated.

    When the FINISH button is clicked more than once, multiple upgrades are initiated against the same bundle.

    Workaround: No workaround. You can see all of the triggered upgrades in the Task panel. All upgrades initiated after the first click of the FINISH button will fail.

  • On-demand pre-checks for vCenter 80U1 bundle might fail in a specific scenario

    The steps for the scenario are listed below:

    1. SDDC-Manager is upgraded to VCF 5.0.0.0 from 4.5.x

    2. BOM components are not upgraded to VCF 5.0.0.0

    3. Bundles for VCF 5.1.0.0 are downloaded and the pre-check is run by selecting 5.1.0.0 as the target version

    4. The on-demand pre-check fails.

    Workaround: The following are the options:

    • Option 1 - Upgrade SDDC-Manager to VCF 5.1.0.0 and run the pre-checks

    • Option 2) Run the vCenter upgrade and check if there are any issues during the stage VCENTER_UPGRADE_INSTALL_PRECHECK.

      Option 3) See KB article 94862 to run the on-demand prechecks Out-of-Band (OOB) and not through VCF.

  • VCF ESXi upgrade fails during post validation due to HA related cluster configuration issue

    The upgrade of ESXi Cluster fails with error that is similar to below error message:

    Cluster Configuration Issue: vSphere HA failover operation in progress in cluster <cluster-name> in datacenter <datacenter-name>: 0 VMs being restarted, 1 VMs waiting for a retry, 0 VMs waiting for resources, 0 inaccessible vSAN VMs

    Workaround: See KB article 90985.

  • Lifecycle Management Precheck does not throw an error when NSX Manager inventory is out of sync

    Workaround None.

  • NSX upgrade may fail if there are any active alarms in NSX Manager

    If there are any active alarms in NSX Manager, the NSX upgrade may fail.

    Workaround: Check the NSX Manager UI for active alarms prior to NSX upgrade and resolve them, if any. If the alarms are not resolved, the NSX upgrade will fail. The upgrade can be retried once the alarms are resolved.

  • SDDC Manager upgrade fails at "Setup Common Appliance Platform"

    If a virtual machine reconfiguration task (for example, removing a snapshot or running a backup) is taking place in the management domain at the same time you are upgrading SDDC Manager, the upgrade may fail.

    Workaround: Schedule SDDC Manager upgrades for a time when no virtual machine reconfiguration tasks are happening in the management domain. If you encounter this issue, wait for the other tasks to complete and then retry the upgrade.

  • Parallel upgrades of vCenter Server are not supported

    If you attempt to upgrade vCenter Server for multiple VI workload domains at the same time, the upgrade may fail while changing the permissions for the vpostgres configuration directory in the appliance. The message chown -R vpostgres:vpgmongrp /storage/archive/vpostgres appears in the PatchRunner.log file on the vCenter Server Appliance.

    Workaround: Each vCenter Server instance must be upgraded separately.

  • When you upgrade VMware Cloud Foundation, one of the vSphere Cluster Services (vCLS) agent VMs gets placed on local storage

    vSphere Cluster Services (vCLS) ensures that cluster services remain available, even when the vCenter Server is unavailable. vCLS deploys three vCLS agent virtual machines to maintain cluster services health. When you upgrade VMware Cloud Foundation, one of the vCLS VMs may get placed on local storage instead of shared storage. This could cause issues if you delete the ESXi host on which the VM is stored.

    Workaround: Deactivate and reactivate vCLS on the cluster to deploy all the vCLS agent VMs to shared storage.

    1. Check the placement of the vCLS agent VMs for each cluster in your environment.

      1. In the vSphere Client, select Menu > VMs and Templates.

      2. Expand the vCLS folder.

      3. Select the first vCLS agent VM and click the Summary tab.

      4. In the Related Objects section, check the datastore listed for Storage. It should be the vSAN datastore. If a vCLS agent VM is on local storage, you need to deactivate vCLS for the cluster and then re-enable it.

      5. Repeat these steps for all vCLS agent VMs.

    2. Deactivate vCLS for clusters that have vCLS agent VMs on local storage.

      1. In the vSphere Client, click Menu > Hosts and Clusters.

      2. Select a cluster that has a vCLS agent VM on local storage.

      3. In the web browser address bar, note the moref id for the cluster.

        For example, if the URL displays as https://vcenter-1.vrack.vsphere.local/ui/app/cluster;nav=h/urn:vmomi:ClusterComputeResource:domain-c8:503a0d38-442a-446f-b283-d3611bf035fb/summary, then the moref id is domain-c8.

      4. Select the vCenter Server containing the cluster.

      5. Click Configure > Advanced Settings.

      6. Click Edit Settings.

      7. Change the value for config.vcls.clusters.<moref id>.enabled to false and click Save.

        If the config.vcls.clusters.<moref id>.enabled setting does not appear for your moref id, then enter its Name and false for the Value and click Add.

      8. Wait a couple of minutes for the vCLS agent VMs to be powered off and deleted. You can monitor progress in the Recent Tasks pane.

    3. Enable vCLS for the cluster to place the vCLS agent VMs on shared storage.

      1. Select the vCenter Server containing the cluster and click Configure > Advanced Settings.

      2. Click Edit Settings.

      3. Change the value for config.vcls.clusters.<moref id>.enabled to true and click Save.

      4. Wait a couple of minutes for the vCLS agent VMs to be deployed and powered on. You can monitor progress in the Recent Tasks pane.

    4. Check the placement of the vCLS agent VMs to make sure they are all on shared storage

  • NSX Data Center upgrade fails at "NSX T PERFORM BACKUP"

    If you did not change the destination of NSX Manager backups to an external SFTP server, upgrades may fail due to an out-of-date SSH fingerprint for SDDC Manager.

    Workaround:

    1. Log in to the NSX Manager UI.

    2. Click System > Backup & Restore.

    3. Click Edit for the SFTP Server.

    4. Remove the existing SSH fingerprint and click Save.

    5. Click Add to add the server provided fingerprint.

    6. Click Save.

    7. Retry the NSX Data Center upgrade from the SDDC Manager UI.

  • You are unable to update NSX Data Center in the management domain or in a workload domain with vSAN principal storage because of an error during the NSX transport node precheck stage

    In SDDC Manager, when you run the upgrade precheck before updating NSX Data Center, the NSX transport node validation results with the following error.

    No coredump target has been configured. Host core dumps cannot be saved.:System logs on host sfo01-m01-esx04.sfo.rainpole.io are stored on non-persistent storage. Consult product documentation to configure a syslog server or a scratch partition.

    Because the upgrade precheck results with an error, you cannot proceed with updating the NSX Data Center instance in the domain. VMware Validated Design supports vSAN as the principal storage in the management domain. However, vSAN datastores do no support scratch partitions. See VMware Knowledge Base article 2074026.

    Disable the update precheck validation for the subsequent NSX Data Center update.

    1. Log in to SDDC Manager as vcf using a Secure Shell (SSH) client.

    2. Open the application-prod.properties file for editing: vi /opt/vmware/vcf/lcm/lcm-app/conf/application-prod.properties

    3. Add the following property and save the file: lcm.nsxt.suppress.prechecks=true

    4. Restart the life cycle management service: systemctl restart lcm

    5. Log in to the SDDC Manager user interface and proceed with the update of NSX Data Center.

  • ESXi upgrade fails with the error "Incompatible patch or upgrade files. Please verify that the patch file is compatible with the host. Refer LCM and VUM log file."

    This error occurs if any of the ESXi hosts that you are upgrading have detached storage devices.

    Workaround: Attach all storage devices to the ESXi hosts being upgraded, reboot the hosts, and retry the upgrade.

Bring-up Known Issues

  • Deploying the management domain using vSphere Lifecycle Manager (vLCM) images fails

    If you deploy the management domain with vLCM images, the deployment may fail with the error vlcm_cluster_creation_postdeploy.py", line 220, in execute AttributeError: 'NoneType' object has no attribute. This can occur when you are using the XLS or JSON file:

    • XLS: When Enable vLCM Cluster Image is set to Yes.

    • JSON: When clusterImageEnabled is set to true.

    The failure is caused by a race condition in vCenter Server installer which fails to create a datacenter once the vCenter Server is deployed.

    Workaround: Contact VMware by Broadcom Support to deploy a vLCM image-based management domain.

  • VM MANAGEMENT port group may get created on the wrong vSphere Distributed Switch (VDS)

    If your bring-up spec contains multiple VDSes and the VM MANAGEMENT and MANAGEMENT networks are on different VDSes, the VM MANAGEMENT port group may get created on the VDS that contains the MANAGEMENT port group, even if you specified different VDSes for VM MANAGEMENT and MANAGEMENT.

    Example section from a bring-up spec that would see this issue:

    {
      "mtu": 8940,
      "dvsName": "SDDC-Dswitch-VDS02",
      "vmnics": [
        "vmnic0",
        "vmnic1"
      ],
      "networks": [
        "MANAGEMENT",
        "VMOTION",
        "VSAN"
      ]
    }

{ "mtu": 8940,
      "dvsName": "SDDC-Dswitch-VDS01",
      "vmnics": [
        "vmnic6",
        "vmnic7"
      ],
      "networks": [
        "VM_MANAGEMENT"
      ]
    }

    Workaround: In the bring-up spec, specify the VDS for the VM MANAGEMENT network first. For example:

    { "mtu": 8940,
      "dvsName": "SDDC-Dswitch-VDS01",
      "vmnics": [
        "vmnic6",
        "vmnic7"
      ],
      "networks": [
        "VM_MANAGEMENT"
      ]
    }
{
      "mtu": 8940,
      "dvsName": "SDDC-Dswitch-VDS02",
      "vmnics": [
        "vmnic0",
        "vmnic1"
      ],
      "networks": [
        "MANAGEMENT",
        "VMOTION",
        "VSAN"
      ]
    }

  • Entering pNICs in non-lexicographic order in the deployment parameter workbook does not work as expected

    When you deploy the management domain by uploading the deployment parameter workbook, the vmnic to uplink mapping for a vSphere distributed switch (vDS) is always done in lexicographic order, regardless of the order that you enter the vmnics in the deployment parameter workbook.

    For example, if you enter vmnic0, vmnic2, vmnic3, vmnic1, the vmnic to uplink mapping will be:

    vmnic0

    Uplink 1

    vmnic1

    Uplink 2

    vmnic2

    Uplink 3

    vmnic3

    Uplink 4

    Workaround: If you want to deploy the management domain with non-lexicographic vmnic to uplink mapping, create and upload a JSON file instead of using the deployment parameter workbook XLSX. See https://developer.vmware.com/apis/vcf/5.1.0/sddc/.

  • Entering more than two pNICs for the primary vDS in the deployment parameter workbook does not work as expected

    If you deploy the management domain by uploading the deployment parameter workbook, there is an issue with converting the XLSX file to JSON when you enter more than two pNICs for the primary vSphere distributed switch (vDS). The result is that only the host overlay network uses all of the pNICs. The management, vSAN, and vMotion networks use only the first two pNICs.

    Workaround: If you want to deploy the management domain with a primary vDS that uses more than two pNICs, create and upload a JSON file instead of using the deployment parameter workbook XLSX. See https://developer.vmware.com/apis/vcf/5.1.0/sddc/.

SDDC Manager Known Issues

  • SDDC Manager UI is showing a vSAN License as Active even though it was not assigned

    If you deployed multiple workload domains using the "License Later" option and added a vSAN license key for one of the workload domains, the other workload domain may also show that there is an Active vSAN license, even though the workload domain is using and Evaluation license.

    Workaround: Use the vSphere Client to check the licensing status and apply a vSAN license if required.

  • Filtering bundles by "Downloaded" in the SDDC Manager UI does not show any results

    If you browse to Lifecycle Management > Bundle Management > Bundles in the SDDC Manager UI and choose Downloaded from the Refine Search drop-down menu, no results are displayed, even if you have downloaded bundles.

    Workaround: Click Download History to view all downloaded bundles or use the script in KB 94760.

  • SDDC Manager license key is not needed

    A SDDC manager license key is not needed, and any errors seen related to an existing SDDC manager license key can be ignored.

    Workaround: None.

  • SoS utility options for health check are missing information

    Due to limitations of the ESXi service account, some information is unavailable in the following health check options:

    • --hardware-compatibility-report: No Devices and Driver information for ESXi hosts.

    • --storage-health: No vSAN Health Status or Total no. of disks information for ESXi hosts.

    None.

Workload Domain Known Issues

  • Cannot add unused vmnics to an existing vSphere Distributed Switch (VDS)

    You may encounter an issue configuring a switch when you are creating a workload domain or adding a cluster to a workload domain in the following circumstances:

    • You create a custom switch configuration and then copy from a preconfigured profile. You can add uplinks to unused vmnics, but the newly added uplinks do not appear when you are configuring the port group.

    • You have configured a VDS and then edit it and add uplinks to unused vmnics. When you try to configure the port group, the newly added uplinks do not appear.

    Workaround: None.

  • Heterogeneous operations "Cluster Creation" and "VI Creation" are not supported to be ran in parallel when they are operating against same shared NSX instance.

    If there is a running VI Creation workflow operating on an NSX resource, then creating a cluster on domains that are sharing that NSX is not possible.

    Workaround: None. The VI Creation workflow should complete before the cluster creation workflow can be started.

  • An unxpected replication agreement is still left after the successful decommission of the SSO node task

    The decommission of the SSO node was successful, but the replication partner remained.

    Workaround: Manually remove the replication agreement of the invalid SSO node, and restart the delete workload domain.

    The vCenter command /usr/lib/vmware-vmdir/bin/vdcrepadmin can be used to add/remove replication agreements.

  • Adding host fails when host is on a different VLAN

    A host add operation can sometimes fail if the host is on a different VLAN.

    1. Before adding the host, add a new portgroup to the VDS for that cluster.

    2. Tag the new portgroup with the VLAN ID of the host to be added.

    3. Add the Host. This workflow fails 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.

    NOTE: If you later remove this host in the future, you must manually remove the portgroup as well if it is not being used by any other host.

  • Deploying partner services on an NSX workload domain displays an error

    Deploying partner services, such as McAfee or Trend, on a workload domain enabled for vSphere Update Manager (VUM), displays the “Configure NSX at cluster level to deploy Service VM” error.

    Attach the Transport node profile to the cluster and try deploying the partner service. After the service is deployed, detach the transport node profile from the cluster.

  • If the witness ESXi version does not match with the host ESXi version in the cluster, vSAN cluster partition may occur

    vSAN stretch cluster workflow does not check the ESXi version of the witness host. If the witness ESXi version does not match the host version in the cluster, then vSAN cluster partition may happen.

    1. Upgrade the witness host manually with the matching ESXi version using the vCenter VUM functionality.

    2. Replace or deploy the witness appliance matching with the ESXi version.

  • vSAN partition and critical alerts are generated when the witness MTU is not set to 9000

    If the MTU of the witness switch in the witness appliance is not set to 9000, the vSAN stretch cluster partition may occur.

    Set the MTU of the witness switch in the witness appliance to 9000 MTU.

  • Adding a host to a vLCM-enabled workload domain configured with the Dell Hardware Support Manager (OMIVV) fails

    When you try to add a host to a vSphere cluster for a workload domain enabled with vSphere Lifecycle Manager (vLCM), the task fails and the domain manager log reports "The host (host-name) is currently not managed by OMIVV." The domain manager logs are located at /var/log/vmware/vcf/domainmanager on the SDDC Manager VM.

    Update the hosts inventory in OMIVV and retry the add host task in the SDDC Manager UI. See the Dell documentation for information about updating the hosts inventory in OMIVV.

  • The vSAN Performance Service is not enabled for vSAN clusters when CEIP is not enabled

    If you do not enable the VMware Customer Experience Improvement Program (CEIP) in SDDC Manager, when you create a workload domain or add a vSphere cluster to a workload domain, the vSAN Performance Service is not enabled for vSAN clusters. When CEIP is enabled, data from the vSAN Performance Service is provided to VMware and this data is used to aid VMware Support with troubleshooting and for products such as VMware Skyline, a proactive cloud monitoring service. See Customer Experience Improvement Program for more information on the data collected by CEIP.

    Enable CEIP in SDDC Manager. See the VMware Cloud Foundation Documentation. After CEIP is enabled, a scheduled task that enables the vSAN Performance Service on existing clusters in workload domains runs every three hours. The service is also enabled for new workload domains and clusters. To enable the vSAN Performance Service immediately, see the VMware vSphere Documentation.

  • Creation or expansion of a vSAN cluster with more than 32 hosts fails

    By default, a vSAN cluster can grow up to 32 hosts. With large cluster support enabled, a vSAN cluster can grow up to a maximum of 64 hosts. However, even with large cluster support enabled, a creation or expansion task can fail on the sub-task Enable vSAN on vSphere Cluster.

    1. Enable Large Cluster Support for the vSAN cluster in the vSphere Client. If it is already enabled skip to step 2.

      1. Select the vSAN cluster in the vSphere Client.

      2. Select Configure > vSAN > Advanced Options.

      3. Enable Large Cluster Support.

      4. Click Apply.

      5. Click Yes.

    2. Run a vSAN health check to see which hosts require rebooting.

    3. Put the hosts into Maintenance Mode and reboot the hosts.

    For more information about large cluster support, see https://kb.vmware.com/kb/2110081.

  • Removing a host from a cluster, deleting a cluster from a workload domain, or deleting a workload domain fails if Service VMs (SVMs) are present

    If you deployed an endpoint protection service (such as guest introspection) to a cluster through NSX Data Center, then removing a host from the cluster, deleting the cluster, or deleting the workload domain containing the cluster will fail on the subtask Enter Maintenance Mode on ESXi Hosts.

    • For host removal: Delete the Service VM from the host and retry the operation.

    • For cluster deletion: Delete the service deployment for the cluster and retry the operation.

    • For workload domain deletion: Delete the service deployment for all clusters in the workload domain and retry the operation.

  • vCenter Server overwrites the NFS datastore name when adding a cluster to a VI workload domain

    If you add an NFS datastore with the same NFS server IP address, but a different NFS datastore name, as an NFS datastore that already exists in the workload domain, then vCenter Server applies the existing datastore name to the new datastore.

    If you want to add an NFS datastore with a different datastore name, then it must use a different NFS server IP address.

check-circle-line exclamation-circle-line close-line
Scroll to top icon