vSphere 7.0 Update 3 was initially released on October 5, 2021. Shortly after release, there were a number of issues reported by customers, so on November 18, 2021, all ESXi versions 7.0 U3a, U3b, U3c, as well as vCenter 7.0 U3b were withdrawn from VMware’s download area. VMware explains details of the issue in KB 86191.
The main reason was a duplicate driver i40en and i40enu for Intel 10 GBit NICs X710 and X722 in the system. A check on the CLI returns a result quickly. Only one result may be returned here.
esxcli software vib list | grep -i i40
Hosts with both drivers will potentially have HA issues when updating to U3c, as well as issues with NSX.
What’s new with Update 3c ?
On 27 January 2022 ( 28 January 2022 CET) the new Update 3c was released and is available for download. Besides fixing the issues from previous Update 3 versions (KB 86191), the main feature is the fix for the Apache Log4j vulnerability (VMSA-2021-0028.10).
All users and customers who had installed one of the withdrawn updates 3 at an early stage are highly recommended to update to version U3c.
One of the new features of vSphere 7.0 Update 3 is that you can now manage NSX-T directly from the vSphere Client. In the new menu of the vSphere client UI, you will now find a section dedicated to NSX.
Opening this section currently brings up an NSX-T status information page. At this current stage, we are able to deploy new NSX-T instances, but existing NSX-T installations won’t be discovered.
Why is that?
As usual, a look at the Release Notes helps. There you’ll find the following statement for vCenter 7 Update 3:
You can see the vSphere Client NSX-T home page that enables the feature, but it does not work with NSX-T Data Center 3.1.x or earlier.
The most recent NSX-T version is 3.1.3 [as of 11/15/2021]. This means we have to wait for NSX-T version 3.2 until the integration works.
I’d like to point your attention to a new and useful feature which was introduced with vSphere 7 update 2. It is easily being overlooked in the abundance of new features, but it does a very good job in the prior to a vCenter update.
A requirement for the Update Planner is participation in the Customer Experience Improvement Program (CEIP).
The first sign of a new vCenter update is a notification banner at the top of vSphere Client.
Clicking on “View Updates” will take you directly to the Update Planner. This can also be found in the menu. To do this, select the vCenter in the Hosts & Clusters view and select “Updates” > vCenter Server > Update Planner in the menu bar at the top right.
All currently available updates are being displayed. In the case shown below, the vCenter is already at 7.0 Update 2, so only one possible update is listed. If several possible updates are available, the Update Planner can check the compatibility against all of them. To do this, select the radio button of the desired update (red box).
Once an update is selected, the action field “Generate Report” turns blue and shows the two possible sub-items “Interoperability” and “Pre-Update Checks“.
The Interoperability Check verifies not only the ESXi hosts but also the compatibility with other VMware products registered in vCenter.
Working with templates has become much easier in vSphere 7 since VMware added new features to content libraries. It is now possible to deploy VMs directly from templates in content libraries and to update templates while the orignal version stays in place.
If there are still classic templates in vCenter, you can clone them to a content library.
Transfer the old template to the content library as a new template.
Failed to export OVF package
After klicking OK, an error message “Failed to export OVF package” might be issued. Usually followed by a second message that leads to the root cause of the problem.
File ds:///vmfs/volumes/vsan:527a6824b9bfa7ad-36f48a2cd78b9685/1f40b55e-f88d-e569-9d66-002590bb2ed0/b02cb65d-e81b-49cb-a654-ef26ea21b2f7/ubuntu-20.04-live-server-amd64_5696e54c-c62a-4fa8-b007-0192a28ff53d.iso was not found
The only interesting part of the message are the last four words: “iso was not found“. Obviously the VM had an iso image mounted before it was converted to a template. Luckily that problem is easy to resolve by converting the template into a VM and removing the iso image from CD-ROM settings. Change it to “Client Device” for example. Convert the VM back to a template and retry cloning to content library. Without a mounted iso image the conversion works without an error.