Error During Pre-patch Vcdb. See Vcdb_patch.err

[Eleanora Parrot]

Forinternationalization, compatibility, installation, upgrade, open source components and product support notices, see the VMware vSphere 7.0 Release Notes.

For more information on vCenter Server supported upgrade and migration paths, please refer to VMware knowledge base article 67077.

When a vSAN stretched cluster has a network partition between sites, a delay in the vSAN health service detecting the partition might cause CNS applications to remove volume-to-datastore mappings in the cache. As a result, attempts to attach such volumes to pods, or run any operations on the volume such as update or delete, fail until CNS volume-to-datastore mappings are restored after the partition is fixed.

Deployment of virtual machines by using an OVF template on a cluster with VMware NSX-T Data Center might fail due to a compatibility check. During OVF template deployments, vCenter Server performs compatibility checks on randomly selected ESXi hosts, and if such a host uses an NSX Distributed Virtual port group, the check might fail due to a missing prerequisite for NVDS to CVDS migration, which in the case of OVF deployments is not necessary.

An issue with the envoy service specific to the VMware Remote Console might lead to intermittent failures of the service. As a result, the vCenter Server Management Interface or vCenter Server APIs might also become unavailable.

Due to some additional permission checks from the vSphere Authentication Proxy service, adding an ESXi host to an Active Directory domain might fail. The issue is specific for vSphere Authentication Proxy configurations where some users do not have Domain Admins privileges on the Active Directory.

In the vSphere Client, even though you set a vCenter cannot start the Fault Tolerance secondary VM alarm, you do not see the alarm when the secondary VM that duplicates a mission critical virtual machine protected by FT fails to start.

OVF export operations by using the vSphere Client complete successfully, but while running, you might see a pop-up window with the error HTTP Status 503 - Service Unavailable. The issue occurs because an export task might be initiated twice. As a result, one of the tasks completes, but the other ends with a 503 error.

If a user in your environment belongs to many Active Directory groups, either nested or not, the Security Token Service (STS) server might take long to issue a SAML token. As a result, login to the vSphere Client of such user might time out and fail. In the vSphere Client, you see a message such as Cannot connect to vCenter Single Sign-On server

This issue is resolved in this release. The fix makes sure that logins to the vSphere Client succeed. However, the fix does not prevent login timeouts due to STS delayed response for a SAML token. As a result, in some environments where a user belongs to many Active Directory groups, you might log in to the vSphere Client, but still not be able to connect to a vCenter Server instance.

Due to an issue with the execution of the expand scripts of the vCenter Server database, incremental patches of vCenter Server 7.x, such as vCenter Server 7.0 Update 2c to VMware vCenter Server 7.0 Update 2d, might fail. In the vSphere Client, you see the error Exception occured in postInstallHook. In the log files, such as /var/log/vmware/applmgmt/vcdb_patch.err and /var/log/vmware/applmgmt/vcdb_patch.out, you see the error vcdb:Patch ERROR vmware_b2b.patching.executor.hook_executor Patch hook 'vcdb:Patch' failed..

Due to the name change in the Intel i40en driver to i40enu and back to i40en, vCenter Server 7.0 Update 3d and later add an upgrade precheck to make sure that ESXi hosts affected from the change are properly upgraded. In some cases, if such hosts exist in your system, patching from a vCenter Server version earlier than 7.0 Update 3 to a version later than 7.0 Update 3 by using CLI might fail with the error Installation failed. Retry to resume from the current state. Or please collect the VC support bundle.. However, instead of this error, you must see the precheck error message.

Workaround: If you do not see the precheck error and patching your system to vCenter Server 7.0 Update 3d fails, make sure all ESXi hosts are upgraded to ESXi 7.0 Update 3d, by using either a baseline created from an ISO or a single image, before upgrading vCenter Server. Do not use patch baselines based on the rollup bulletin. You can find additional debug log information at /var/log/vmware/applmgmt. For more details, see VMware knowledge base articles 87319 and 86447.

In vCenter Server 7.0 Update 1, vSphere Cluster Services adds a set of system virtual machines in every vSphere cluster to ensure the healthy operation of vSphere DRS. The system virtual machines deploy automatically with an implicit datastore selection logic. Depending on your cluster configuration, the system virtual machines might impact some of the cluster and datastore maintenance workflows.

The supported upgrade sequence for vSphere systems is first to upgrade vCenter Server and then ESXi. However, in certain environments with ESXi hosts of version 7.0 Update 2d and later, you need to update ESXi first to 7.0 Update 3c and then vCenter Server. Such an upgrade sequence requires additional steps to force a full host-sync.

Due to the name change in the Intel i40en driver to i40enu and back to i40en, vCenter Server 7.0 Update 3c adds an upgrade precheck to make sure that ESXi hosts affected from the change are properly upgraded. However, if you apply an ESXi hot patch that is released after vCenter Server 7.0 Update 3c and then upgrade your system to vCenter Server 7.0 Update 3c, the hot patch might not be listed in the precheck. As a result, you might not follow the proper steps to the upgrade and vSphere HA might fail to configure on such hosts.

The vCenter Server Upgrade/Migration pre-checks fail when the Security Token Service (STS) certificate does not contain a Subject Alternative Name (SAN) field. This situation occurs when you have replaced the vCenter 5.5 Single Sign-On certificate with a custom certificate that has no SAN field, and you attempt to upgrade to vCenter Server 7.0. The upgrade considers the STS certificate invalid and the pre-checks prevent the upgrade process from continuing.

After upgrade, previously installed 32-bit CIM providers stop working because ESXi requires 64-bit CIM providers. Customers may lose management API functions related to CIMPDK, NDDK (native DDK), HEXDK, VAIODK (IO filters), and see errors related to uwglibc dependency.

The syslog reports module missing, "32 bit shared libraries not loaded."

Workaround: To patch your system to vCenter Server 7.0 Update 1 from earlier versions of vCenter Server 7.x, you must remove vCenter Server High Availability and delete the passive and witness nodes. After the upgrade, you must re-create your vCenter Server High Availability clusters.

If you try to migrate a 6.x vCenter Server system to vCenter Server 7.x by using the VMware Migration Assistant, and your system has a Windows OS, and uses an external database with a password containing non-ASCII characters, the operation fails. For example, Admin!23迁移. In the Migration Assistant console, you see the following error:

Workaround: If you run the update by using the vCenter Server Management Interface, you must provide the vCenter Single Sign-On administrator password.

If you run the update by using software-packages or CLI in an interactive manner, you must interactively provide the vCenter Single Sign-On administrator password.

If you run the update by using software-packages or CLI in a non-interactive manner, you must provide the vCenter Single Sign-On administrator password by an answer file in the format

"vmdir.password": "SSO Password of Administrator@ user"

If you have configured vCenter Server for either Smart Card or RSA SecurID authentication, see the VMware knowledge base article at before starting the vSphere 7.0 upgrade process. If you do not perform the workaround as described in the KB, you might see the following error messages and Smart Card or RSA SecurID authentication does not work.

If you start an operation to apply or remove NSX while adding multiple ESXi hosts by using a vSphere Lifecycle Manager image to a vSphere HA-enabled cluster, the NSX-related operations might fail with an error in the vSphere Client such as:

vSphere HA agent on some of the hosts on cluster is neither vSphere HA master agent nor connected to vSphere HA master agent. Verify that the HA configuration is correct.

The issue occurs because vSphere Lifecycle Manager configures vSphere HA for the ESXi hosts being added to the cluster one at a time. If you run an operation to apply or remove NSX while vSphere HA configure operations are still in progress, NSX operations might queue up between the vSphere HA configure operations for two different ESXi hosts. In such a case, the NSX operation fails with a cluster health check error, because the state of the cluster at that point does not match the expected state that all ESXi hosts have vSphere HA configured and running. The more ESXi hosts you add to a cluster at the same time, the more likely the issue is to occur.

When you upgrade a vCenter Server deployment using an external Platform Services Controller, you converge the Platform Services Controller into a vCenter Server appliance. If the upgrade fails with the error install.vmafd.vmdir_vdcpromo_error_21, the VMAFD firstboot process has failed. The VMAFD firstboot process copies the VMware Directory Service Database (data.mdb) from the source Platform Services Controller and replication partner vCenter Server appliance.

Workaround: Disable TCP Segmentation Offload (TSO) and Generic Segmentation Offload (GSO) on the Ethernet adapter of the source Platform Services Controller or replication partner vCenter Server appliance before upgrading a vCenter Server with an external Platform Services Controller. See Knowledge Base article:

3a8082e126