 Docs

Docs / VMware vSphere

VMware vCenter Server 8.0

Update 3c Release Notes
Только текст Отзывы  Поделиться

Дата обновления 10.10.2024

vCenter Server 8.0 Update 3c | 09 OCT 2024 |

ISO Build 24305161

Check for additions and updates to these release

notes.

What's New

This release resolves an issue with the vSphere

Client becoming unresponsive when a session
stays idle for more than 50 minutes. For more
information, see Resolved Issues.

Earlier Releases of vCenter Server 8.0

Features, resolved and known issues of vCenter

Server are described in the release notes for each
release. Release notes for earlier releases of vCenter
Server 8.0 are:

VMware vCenter Server 8.0 Update 3b Release

Notes

VMware vCenter Server 8.0 Update 3a Release

Notes

VMware vCenter Server 8.0 Update 3 Release

Notes

VMware vCenter Server 8.0 Update 2d Release

Notes

VMware vCenter Server 8.0 Update 1e Release

Notes

VMware vCenter Server 8.0 Update 2c Release

Notes

VMware vCenter Server 8.0 Update 2b Release

Notes

VMware vCenter Server 8.0 Update 2a Release

Notes

VMware vCenter Server 8.0 Update 1d Release

Notes

VMware vCenter Server 8.0 Update 2 Release

Notes

VMware vCenter Server 8.0 Update 1c Release

Notes

VMware vCenter Server 8.0 Update 1b Release

Notes

VMware vCenter Server 8.0 Update 1a Release

Notes

VMware vCenter Server 8.0 Update 1 Release

Notes

VMware vCenter Server 8.0c Release Notes

VMware vCenter Server 8.0b Release Notes

VMware vCenter Server 8.0a Release Notes

For internationalization, compatibility, installation,

upgrade, open source components and product
support notices, see the VMware vSphere 8.0
Release Notes.

For more information on vCenter Server supported

upgrade and migration paths, please refer to
VMware knowledge base article 67077.

Patches Contained in This Release

Patch for VMware vCenter Server 8.0 Update

3c
Download and Installation

Patch for VMware vCenter Server 8.0 Update 3c

This patch is applicable to vCenter Server.

Download
VMware-vCenter-Server-Applianc
Filename

Build 24305161

Download Size 8556.0 MB

sha256checksum fc44d794f02756296b7a9f1b0829

PRs fixed 3439359

CVEs N/A

Download and Installation

Log in to the Broadcom Support Portal to download

this patch.

For more information on using the vCenter Server

shells, see VMware knowledge base article 2100508.

For more information on patching vCenter Server,

see Patching and Updating vCenter Server 8.0
Deployments.

For more information on staging patches,

see Upgrading the vCenter Server Appliance.

Resolved Issues

vCenter Server and vSphere Client Issues

vCenter Server and vSphere Client Issues

PR 3439359: If a vSphere Client session stays

idle for more than 50 minutes, the vSphere
Client becomes unresponsive

If you start a vSphere Client session and leave

it idle for more than 50 minutes, the session
becomes invalid and you cannot log in or log
out, or use the vSphere Client from the same
browser until you clear all cookies. The issue
occurs due to an upgrade to Apache Tomcat
9.0.91 in vSphere 8.0 Update 3b, which
changes the default value of the property
org.apache.catalina.connector.RECYCLE_FACAD
ES to TRUE from FALSE.

This issue is resolved in this release.

Known Issues from Previous Releases

Installation, Upgrade, and Migration Issues

Miscellaneous Issues
Networking Issues
Storage Issues
vCenter Server and vSphere Client Issues
Virtual Machine Management Issues
vSphere Lifecycle Manager Issues
VMware Host Client Issues
Security Features Issues

Installation, Upgrade, and Migration Issues

You see a security warning for the ESX Agent

Manager configuration during the pre-check
phase of a vCenter upgrade

During the pre-check phase of a vCenter

update or upgrade, in the vSphere Client and
logs, you might see an error such as:

Source ESX Agent Manager Configuration

contains URLs that are not trusted by the
System! Please refer to
https://kb.vmware.com/s/article/93526
to trust the URLs: <LIST_OF_URLs>

Or

Source vSphere ESX Agent Manager (EAM)

upgrade failed to obtain EAM URLs to check
against trusted certificates by the System!
Verify that the ESX Agent Manager extension
is running properly on the source vCenter
Server instance and
https://VC_IP/eam/mob presents correct
data. If log in to the MOB is not
successful, try resolving the issue with
https://kb.vmware.com/s/article/94934.

Workaround: For more information, see

VMware knowledge base articles 93526 and
94934.

If you do not open port 9087 in your firewall

between ESXi hosts and vCenter, compliance
checks and vSphere HA might fail after
vCenter update to 8.0 Update 3

Starting from 8.0 Update 3, the vSphere

Lifecycle Manager downloads updates for ESXi
hosts by a HTTPS connection to the vCenter
instance on port 9087. If you do not open port
9087 in your firewall between ESXi hosts and
vCenter, you might see compliance check
errors. For example, in the lifecycle.log you
see messages such as:

<Timestamp> In(14) lifecycle[2112988]:

Downloader:373 Opening https://<VC-
FQDN>:9087/vum/repository/hostupdate/__micr
o-depot__vendor-DEL__DEL-ESXi-8.0-Addon-
cumulative_metadata__index__.xml for
download

<Timestamp> Wa(12) lifecycle[2112988]:

Downloader:210 Download failed: <urlopen
error timed out>, 9 retry left...

In addition, vSphere HA might fail to start.

Workaround: Open port 9087 in your firewall

between ESXi hosts and vCenter by using the
TCP protocol.

In a mixed vSphere 7.x and 8.x environment

with vSphere DRS, an incompatible virtual
machine might prevent an ESXi host to enter
maintenance mode

In a mixed vSphere 7.x and 8.x environment

with DRS, a VM of 7.x version that is not
compatible with ESXi 8.0 Update 1 and later
might prevent an ESXi 8.0 Update 1 host to
enter maintenance mode. The issue is specific
for virtual machines with VMDK on a vSphere
Virtual Volumes datastore. In the vSphere
Client, you see an error such as Waiting for all
VMs to be powered off or suspended or
migrated. In a DRS cluster check the Faults
page on the DRS tab for troubleshooting.

Workaround: Power-off the incompatible virtual

machine.

vSphere Lifecycle Manager baseline check

compliance fails on ESXi hosts of version 7.0
GA in a vCenter 8.0 Update 3 system

Due to a limitation of the esxupdate memory

resource pool on 7.0 GA ESXi hosts, a vSphere
Lifecycle Manager baseline check compliance
scan might fail on 7.0 GA ESXi host in a
vCenter 8.0 Update 3 system with error such
as The host returns esxupdate error codes:
-1.

The host esxupdate.log contains an error such

as:

<Timestamp> esxupdate: <PID>: esxupdate:

ERROR: vmware.runcommand.RunCommandError:

Error running command

'['/sbin/smbiosDump']': [Errno 12] Cannot
allocate memory

The vmkernel.log contains error such as:

<Timestamp> cpu0:<PID>)Admission failure in

path: host/vim/vmvisor/esxupdate/python.
<PID>:python.<PID>:uw.<PID>

This issue is specific for 7.0 GA ESXi hosts, as

esxupdate memory allocation is increased in 7.0
Update 1 and later.

Workaround: Use an ISO upgrade baseline to

upgrade the 7.0 GA ESXi hosts to a 8.x version
or revert the vCenter system back to version
7.0 and upgrade the hosts to a version of 7.0
Update 1 and later.

You see an error Failed to get ceip status in

the Virtual Appliance Management Interface
(VAMI) during update to vCenter Server 8.0
Update 1

During an update, vCenter stops and restarts

the VMDir service and within this interval, if you
try to log in to the VAMI, you might see an
error such as Failed to get ceip status. This is
expected and does not indicate an actual issue
with the vCenter system.

Workaround: Wait for the VMDir service to

restart and refresh the Virtual Appliance
Management Interface.

If you click NEXT before the progress bar

reaches 100% in a vCenter Server Lifecycle
Manager plug-in upgrade, the Server Lifecycle
Manager service fails

In the Upgrade Plug-in step of the vCenter

Server Lifecycle Manager plug-in upgrade
wizard, if you click NEXT before the progress
bar reaches 100%, the Server Lifecycle
Manager service fails.

Workaround: Wait for the progress bar to

reach 100% before you click NEXT.

vCenter upgrade or update to 8.0 Update 2a

or later fails during precheck with the error
"VMCA root certificate validation failed"

If your vCenter system has a legacy VMCA root

certificate dating back to version 5.x which
does not have the Subject Key Identifier (SKID)
extension, upgrades and updates to vCenter
8.0 Update 2 and later fail because the
OpenSSL version 3.0 in 8.0 Update 2 is not
compatible with legacy root certificates.
vCenter Server 8.0 Update 2a adds a precheck
to detect this issue and shows the error
message VMCA root certificate validation
failed if the source vCenter has VMCA root
certificate without SKID.

Workaround: Regenerate a VMCA root

certificate by following the steps in VMware
knowledge base article 94840.

You see a "vc.health.error.dbjob3" warning

after a vCenter upgrade

In the vSphere Client or the in Virtual Appliance

Management Interface, you might see the
warning vc.health.error.dbjob3 after a
vCenter upgrade although the vCenter overall
health status is green. This issue does not
affect vCenter operations, it can only affect
historical statistics when some data does not
roll up for more than 72 hours.

Workaround: See Delete old tasks, events and

statistics data in vCenter Server 5.x, 6.x, 7.x
and 8.x how to clear stats data, if not relevant
anymore.

A reduced downtime upgrade (RDU) on a

vCenter system might fail when you use
Update Planner

During RDU, if you use Update Planner, in the

vSphere Client you might see an error such as:
Update 8.0.2.00000 for component vlcm is
not found.

Workaround: For more information, see

VMware knowledge base articles 94779 and
92659.

Update to vCenter 8.0 Update 3 might fail

with an error "Destination path
'/storage/analytics/stage/...' already exists"

Starting with vCenter 8.0 Update 3, the

analytics service stores telemetry log files in a
new directory.

In rare cases, if previous update attempts had

failed and reverted, when patching to vCenter
8.0 Update 3, the attempt to copy the
telemetry log files to the new location might fail
because these files already exist from a prior
patching attempt. In the patchrunner.log file,
you see an error such as Destination path
'/storage/analytics/stage/XXXXXX_processed_
logs' already exists.

Workaround: Delete all files under

/storage/log/vmware/analytics/stage,/storag
e/log/vmware/analytics/prod,
/storage/analytics/stage, and
/storage/analytics/prod, and retry the
update.

Failed parallel remediation by using vSphere

Lifecycle Manager on one ESXi host might
cause other hosts to remain in a pending
reboot state

An accidental loss of network connectivity

during a parallel remediation by using vSphere
Lifecycle Manager might cause the operation
to fail on one of the ESXi hosts. Remediation on
other hosts continues, but the hosts cannot
reboot to complete the task.

Workaround: If an ESXi host consistently fails

remediation attempts, manually trigger a
reboot. For more information, see VMware
knowledge base article 91260.

You see a security warning for the ESX Agent

Manager configuration during the pre-check
phase of a vCenter upgrade

During the pre-check phase of a vCenter

update or upgrade, in the vSphere Client and
logs, you might see an error such as:

Source ESX Agent Manager Configuration

contains URLs that are not trusted by the
System! Verify following URLs and their
respective statuses and follow KB 93526.

Workaround: For more information, see

VMware knowledge base article 93526.

Firmware compliance details are missing from

a vSphere Lifecycle Manager image
compliance report for an ESXi standalone host

Firmware compliance details might be missing

from a vSphere Lifecycle Manager image
compliance report for an ESXi standalone host
in two cases:

1. You run a compliance report against a

standalone host managed with a vSphere
Lifecycle Manager image from vSphere
Client and then navigate away before the
compliance report gets generated.

2. You trigger a page refresh after the

image compliance reports are generated.

In such cases, even when you have the

firmware package available in the Desired
State, the firmware compliance section remains
empty when you revisit or refresh the vSphere
Client browsing session. If you use GET image
compliance API, then firmware compliance
details are missing from the response.

Workaround: Invoke the image compliance

scan for a standalone host managed with a
vSphere Lifecycle Manager image by using the
vSphere Client and do not navigate away or
refresh the browser. For API, use the Check
image compliance API for fetching the firmware
details as apposed to GET image compliance.

You see vCenter update status as failed

although it completes successfully

A rare race condition might cause vCenter to

report a successful update as failed. The issue
occurs if during vCenter reboot /storage/core
unmounts before the system acknowledges the
Installation complete status. As a result, the
update fails with an error such as No such file
or directory: '/storage/core/software-
update/install_operation'. In the software-
packages.logs, you see errors such as:

2023-08-17T10:57:59.229
[15033]DEBUG:vmware.appliance.update.update
_state:In State._get using state file
/etc/applmgmt/appliance/software_update_sta
te.conf

2023-08-17T10:57:59.229
[15033]INFO:vmware.appliance.update.update_
state:Found operation in progress
/storage/core/software-
update/install_operation

2023-08-17T10:57:59.229
[15033]ERROR:vmware.appliance.update.update
_functions:Can't read JSON file
/storage/core/software-
update/install_operation [Errno 2] No such
file or directory: '/storage/core/software-
update/install_operation'

2023-08-17T10:57:59.229
[15033]DEBUG:vmware.appliance.update.update
_state:Operation in progress is orphaned

2023-08-17T10:57:59.229
[15033]DEBUG:vmware.appliance.update.update
_state:Operation in progress is finished

2023-08-17T10:57:59.229
[15033]DEBUG:vmware.appliance.update.update
_state:Writing to state file from
State._get

2023-08-17T10:57:59.229
[15033]DEBUG:vmware.appliance.update.update
_state:In State._writeInfo writing to state
file
/etc/applmgmt/appliance/software_update_sta
te.conf

2023-08-17T10:57:59.229
[15033]INFO:vmware.vherd.base.software_upda
te:Installation failed. Please collect the
VC support bundle.

Workaround: Check if vCenter restarts

successfully and the vCenter health status is
green, and ignore the failure report.

Patching to vCenter 8.0 Update 2 fails in IPv6

environments with no DNS server and
hostname

When you update your vCenter system to 8.0

Update 2 from an earlier version of 8.x, if your
system uses an IPv6 network without a
hostname, such as PNID, and a DNS server, in
the VMware Appliance Management Interface
you might see an error such as Data
conversion/Post install hook failed.

Workaround: Manually update the /etc/hosts

file with the missing IPv6 loopback entry: ::1
localhost ipv6-localhost ipv6-loopback and
reboot the system.

See this example:

root@localhost []# cat /etc/hosts

# Begin /etc/hosts (network card version)

127.0.0.1 localhost.localdomain

127.0.0.1 localhost

::1 localhost ipv6-localhost ipv6-loopback

If you apply a host profile using a software

FCoE configuration to an ESXi 8.0 host, the
operation fails with a validation error

Starting from vSphere 7.0, software FCoE is

deprecated, and in vSphere 8.0 software FCoE
profiles are not supported. If you try to apply a
host profile from an earlier version to an ESXi
8.0 host, for example to edit the host
customization, the operation fails. In the
vSphere Client, you see an error such as Host
Customizations validation error.

Workaround: Disable the Software FCoE

Configuration subprofile in the host profile.

During a reduced downtime upgrade (RDU),

when configuring Target VM network settings,
you see no network portgroups

In very rare cases, during a reduced downtime

upgrade of a single self-managed vCenter
instance that uses a migration-based method,
when a source vCenter VM has thin disk
provisioning and the target vCenter cluster
does not have enough storage to
accommodate the required space for the
default thick disk mode selected by the
validation process, you might see no network
portgroups in the Target VM deployment
wizard. In the vSphere Client, if you select
Same Configuration in the Deployment type
step of the Target VM deployment wizard, you
see an empty error message in the Network
Settings screen and no portgroups available.

Workaround: In the Deployment type step of

the Target VM deployment wizard, select
Detailed Configuration.

You cannot use ESXi hosts of version 8.0 as a

reference host for existing host profiles of
earlier ESXi versions

Validation of existing host profiles for ESXi

versions 7.x, 6.7.x and 6.5.x fails when only an
8.0 reference host is available in the inventory.

Workaround: Make sure you have a reference

host of the respective version in the inventory.
For example, use an ESXi 7.0 Update 2
reference host to update or edit an ESXi 7.0
Update 2 host profile.

URL-based patching or file-based backup of

vCenter 8.0 Update 2 might fail due to
OpenSSL noncompliance to Federal
Information Processing Standards (FIPS)

With vCenter 8.0 Update 2, OpenSSL works

only with Diffie-Hellman parameters compliant
to NIST SP 800-56A and FIPS 140-2. For URL-
based patching or file-based backup of
vCenter 8.0 Update 2 systems, FTPS servers in
your environment must support the following
ciphers:

OpenSSL
Cipher Name AT-TLS Cipher Suite Name
Suite

DHE-
RSA-
TLS_DHE_RSA_WITH_AES_256_CB
AES256-
SHA

DHE-
DSS-
TLS_DHE_DSS_WITH_AES_256_CB
AES256-
SHA

AES256-
TLS_RSA_WITH_AES_256_CBC_SH
SHA

EDH-
RSA-
DES- TLS_DHE_RSA_WITH_3DES_EDE_
CBC3-
SHA

EDH-
DSS-
DES- TLS_DHE_DSS_WITH_3DES_EDE_C
CBC3-
SHA

DES-
CBC3- TLS_RSA_WITH_3DES_EDE_CBC_S
SHA

DHE-
RSA-
TLS_DHE_RSA_WITH_AES_128_CB
AES128-
SHA

DHE-
DSS-
TLS_DHE_DSS_WITH_AES_128_CB
AES128-
SHA

AES128-
TLS_RSA_WITH_AES_128_CBC_SH
SHA

Workaround: Make sure your file servers are

FIPS compliant.

VMNICs might be down after an upgrade to

ESXi 8.0

If the peer physical switch of a VMNIC does not

support Media Auto Detect, or Media Auto
Detect is disabled, and the VMNIC link is set
down and then up, the link remains down after
upgrade to or installation of ESXi 8.0.

Workaround: Use either of these 2 options:

1. Enable the option media-auto-detect in

the BIOS settings by navigating to
System Setup Main Menu, usually by
pressing F2 or opening a virtual console,
and then Device Settings > <specific
broadcom NIC> > Device Configuration
Menu > Media Auto Detect. Reboot the
host.

2. Alternatively, use an ESXCLI command

similar to: esxcli network nic set -S
<your speed> -D full -n <your nic>.
With this option, you also set a fixed
speed to the link, and it does not require
a reboot.

After upgrade to ESXi 8.0, you might lose

some nmlx5_core driver module settings due
to obsolete parameters

Some module parameters for the nmlx5_core

driver, such as device_rss, drss and rss, are
deprecated in ESXi 8.0 and any custom values,
different from the default values, are not kept
after an upgrade to ESXi 8.0.

Workaround: Replace the values of the

device_rss, drss and rss parameters as
follows:

device_rss: Use the DRSS parameter.

drss: Use the DRSS parameter.