vCenter server service on VCSA 6.7.0.43000 crashed and will not start after mounting an ISO on a VM

[IWSLodge]

Summary

vCenter server service on VCSA 6.7.0.43000 crashed and will not start after mounting an ISO from a Content Library on a VM.

I believe this is related to an ISO mapped to a VM from a content library with an entry that is too long (String too large: 524 > max(510)).
I have unmapped the ISO from the VM on the host itself, but the error continues on vpxd.log. I guess that there is a process with the long string stored and it's pending delivery into the inventory DB. I'd like to reset that process and can delete the VM if necessary.

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

Background

This is a brand new vCenter just after being created.  I created several VMs from OVA images with no issue.

This is the first ISO I have uploaded to a new content library, stored on a vSAN volume provided by 6 nodes.

This is the first VM I attached to the ISO and vCenter crashed pretty much immediately.

Type: vCenter Server with an embedded Platform Services Controller
Product: VMware vCenter Server Appliance
Version: 6.7.0.43000
Build number: 15976714

I can logon to the vCenter HTML5 client, but no content is being displayed.

"Could not connect to one or more vCenter Server systems:https://[vcenter]:443/sdk"

Detail# grep 37706 /var/log/vmware/vpxd/vpxd.log
2021-01-29T11:18:53.780Z info vpxd[37706] [Originator@6876 sub=ThreadPool] Thread enlisted
2021-01-29T11:18:53.780Z info vpxd[37706] [Originator@6876 sub=ThreadPool] Entering worker thread loop
2021-01-29T11:18:54.621Z info vpxd[37706] [Originator@6876 sub=ThreadPool] Spawning additional worker - allocated: 122, idle: 6
2021-01-29T11:18:54.622Z info vpxd[37706] [Originator@6876 sub=ThreadPool] Spawning additional worker - allocated: 123, idle: 7
2021-01-29T11:18:57.494Z info vpxd[37706] [Originator@6876 sub=Vsan opID=QS-host-96-409434ca] [CheckDatastoreCapacity] Clearing DatastoreNoCapacity configIssue
2021-01-29T11:19:04.697Z warning vpxd[37706] [Originator@6876 sub=VpxProfiler opID=QS-host-96-409434ca] Vds::Sync::ProcessHostConfigChange [ProcessHostConfigChangeTime] took 5680 ms
2021-01-29T11:19:04.697Z warning vpxd[37706] [Originator@6876 sub=VpxProfiler opID=QS-host-96-409434ca] Vds::Sync::ProcessHostChangeInfo [DvsProcessHostChangeTime] took 5681 ms
2021-01-29T11:19:04.889Z info vpxd[37706] [Originator@6876 sub=MoHost opID=QS-host-96-409434ca] Host [vim.HostSystem:host-96,[edit]esx005.[edit]] hardware ID string: [edit: removed device specifics]
2021-01-29T11:19:05.253Z error vpxd[37706] [Originator@6876 sub=Default opID=QS-host-96-409434ca] [Vdb::VdbField] Invalid value written to column DEVICE_INFO_SUMMARY in table VPX_VM_SN_VIRTUAL_DEVICE
2021-01-29T11:19:05.253Z error vpxd[37706] [Originator@6876 sub=Default opID=QS-host-96-409434ca] [Vdb::VdbField] String too large: 524 > max(510)
2021-01-29T11:19:05.253Z error vpxd[37706] [Originator@6876 sub=Default opID=QS-host-96-409434ca] [VdbStatement::Execute]Bind parameters have different batch size

[Phil52 · Accepted solution]

Hello @IWSLodge 

We had a similar issue, were the person added spaces to the name of the iso, for some reason the spaces caused the issue as the name was way less than the 510 string limit. 

Here is the KB we were referenced from support https://kb.vmware.com/s/article/55610?lang=en_US

But we also edited the VCDB database to max at 1000 characters.

I would recommend reaching out to support if the KB does not help to get the commands to edit the VCDB. 

[IWSLodge]

Thank you @Phil52, I didn't want to adjust the DB schema without another reference site.  My other searches for this issue have been fruitless.

The KB (thanks for that) you sent on suggests that I can adjust the VM config so I'll try that before I adjust the schema. 

I'll look into both solutions and feed back the outcome.

[IWSLodge]

Success!

I followed the instructions in https://kb.vmware.com/s/article/56359 with the caveat below.

Given that the article suggested setting the field length to 512, and the limit applied in this vCenter version was 510 (512-2), I opted to set the limit arbitrarily to 766 (768 - 2).  The errors I was getting in vpxd.log showed a length of 524 so I thought that this was a good initial step.

The vCenter server service started first time afterwards and full control is available again.

It's time to take a full backup before anything else!

Thanks again @Phil52 for sharing your experience.