Highlighted
Enthusiast
Enthusiast

vCetner 6.7 U2 VUM not detecting VM Hardware version 15

I'm having an issue with vCenter 6.7 U2 not listing and detecting that VM Hardware version 15 is an option.

All of my hosts are running the latest build of 6.7 released a few days ago, and the issue is still present even in this build (also present in initial 6.7 U2 build)

If I select my cluster, go to updates, and then select VM Hardware, it's incorrectly reporting my "Host compatibility" and "VM compatibility".

All of my VMs have been upgraded to version 15, but are still listed as version 14.

Regardless of how I configure my "Default VM Compatibility", all my VMs show the "Host compatibility" as version 14.

Running a "check status" for a VM results in an error message and the task failing.

The error message is: "Errors during the scan operation for virtual hardware upgrade"

Is anyone else having this issue?

Thanks

13 Replies
Highlighted
Contributor
Contributor

I am having the same problem with the same versions. Just discovered it today.

0 Kudos
Highlighted
Contributor
Contributor

I have the same problem.

Can not parse ----   for virtual hardware upgrades.

0 Kudos
Highlighted
Enthusiast
Enthusiast

6.7 U3 still seems to have the same problem (Upgraded my "U2" environment).

No one have any suggestions?

Thanks!

0 Kudos
Highlighted
Enthusiast
Enthusiast

I've gone through the "VMware-vum-server-log4cpp" log file and can see the entries below for my servers during the scan process

'SingleVMHardwareScanTask.SingleVMHardwareScanTask{417}' 140443735303936 ERROR]  [singleVMHardwareScanTask, 365] VDB error while saving compliance state "ODBC error: (23503) - ERROR: insert or update on table "vci_vmhw_scanresults" violates foreign key constraint "fk_vci_sres_ref_versions"; Error while executing the query" is returned when executing SQL statement "UPDATE VCI_VMHW_SCANRESULTS SET additional_details = ?, host_vmhw_id = ?, scanh_id = ?, target_uid = ?, target_vmhw_id = ? WHERE target_uid = ?"

'SingleVMHardwareScanTask.SingleVMHardwareScanTask{417}' 140443735303936 ERROR]  [singleVMHardwareScanTask, 432] Scanning error for VM xxxxxxx(vm-34): Error while scanning: VDB error while saving compliance state "ODBC error: (23503) - ERROR: insert or update on table "vci_vmhw_scanresults" violates foreign key constraint "fk_vci_sres_ref_versions"; Error while executing the query" is returned when executing SQL statement "UPDATE VCI_VMHW_SCANRESULTS SET additional_details = ?, host_vmhw_id = ?, scanh_id = ?, target_uid = ?, target_vmhw_id = ? WHERE target_uid = ?"

I can also see entries showing that the host recommended version is 14 (which matches what VUM is showing), but is "wrong" as my cluster/server config is set to use version 15.

'SingleVMHardwareScanTask.SingleVMHardwareScanTask{420}' 140443733174016 INFO]  [singleVMHardwareScanTask, 403] Host recomended version is 14

Anyone with the same issue and a support contract able to log a support ticket to investigate? Smiley Happy

0 Kudos
Highlighted
Contributor
Contributor

I as well have been having this problem, as others mentioned with ESXi 6.7 U2 and now U3 as well. Just the same too, the VMs are showing version 15 on the summary page, VUM is recommending 14 as the target version. Any time I try to remediate the problem I get the same error.

0 Kudos
Highlighted
Contributor
Contributor

I have the same issue on 6.7 U3.

I have a couple of machines which hasnt be upgraded in quite some time, upgrading these to 6.7 and later (version 14), it all works as expected, but if you upgrade to 6.7 Update 2 or later, it then shows unknown. 

vCenter has been upgraded to U3 also as well as all ESX hosts.

VM's are still working but I do not like errors.  You also error when you try and scan.

Any solution as I know theres no 'known' way to downgrade a VM?

Thanks in advance.

pastedImage_0.png

pastedImage_1.png

0 Kudos
Highlighted
Contributor
Contributor

Found a fix by reading:

How to downgrade the hardware version of a VM?

If you change:

virtualHW.version = “15”

replace with:

virtualHW.version = “14”

which is the exact version which works (cross checked), it then is fine.

Not sure what the long term impact of this is i.e. when we can upgrade again, so if anyone knows, let me know.

Thanks

0 Kudos
Highlighted
VMware Employee
VMware Employee

Technically its unsupported to hack the vmx file this way, there are 3 "supported" ways to change HW VMware Knowledge Base

0 Kudos
Highlighted
Contributor
Contributor

After opening a ticket with VMware, this is a known bug and this is the link they sent me to:

https://kb.vmware.com/s/article/1028019

The suggested fix for now is to downgrade v15 machines to v14 until a fix is implemented on the "next major release."

0 Kudos
Highlighted
VMware Employee
VMware Employee

VMware Knowledge Base

Official kb is out for this issue, see above

Highlighted
Contributor
Contributor

Thanks very much for updating thread with "official" solution and ack. 

0 Kudos
Highlighted
User Moderator
User Moderator

Hi,

https://haveyoutriedreinstalling.com/2019/04/12/virtual-hardware-version-15/

Remember, vHW15 won’t run on anything earlier than ESXi 6.7 U2 so unless you have updated all ESXi hosts, at least within a cluster, you could run the risk that vHW15 VMs are restricted to only the hosts currently running ESXi 6.7 U2 which might reduce their mobility and availability potential while the cluster is comprised of mixed patch levels.

vHW15 is also not currently compatible with VMware Cloud on AWS.

The only difference between vHW15 and vHW14 is the number of vCPU a VM can supported. vHW15 increases this to 256 vCPU compared to vHW14 128 vCPU.

When creating new VMs using the vSphere Client, vHW14 will still be the default version in vSphere 6.7 U2.

For more on vHW versions and their features check out:

Hardware Features Available with Virtual Machine Compatibility Settings

pastedImage_15.png

Best regards,

Alessandro Romeo

Blog: https://www.aleadmin.it/
0 Kudos
Highlighted
Contributor
Contributor

Hi,

Thanks very much for filling in the missing piece of the puzzle. 

Thankfully in my case all hosts were already 6.7 U2 and most have been upgraded to 6.7 U3 already before I started seeing this issue.

When the next patches comes out for vCenter and ESX, hopefully then can upgrade them normally as I do try and keep things always at the latest level.

Kind Regards,

Simon

0 Kudos