I have finally found time to update my homelab/server from VMware ESXi 7 to 8, it was mostly seamless apart from an issue with GhettoVCB.

[ProfileValidationError]
 In ImageProfile (Updated) ESXi-8.0b-21203435-standard, the payload(s) in VIB virtuallyGhetto_bootbank_ghettoVCB_1.0.0-0.0.0 does not have sha-256 gunzip checksum. This will prevent VIB security verification and secure boot from functioning properly. Please remove this VIB or please check with your vendor for a replacement of this VIB

GhettoVCB is a utility for those of us using ESXi as a hypervisor on its own, and not plumping up the cash for vSphere (which is entirely overkill in a domestic or lab environment).  It automates backing up of virtual machines to a data store or NFS share, which can be setup on a cron job.  An absolute must if you need "bare metal" recovery for your virtual machines.

Unfortunately there doesn't yet seem to be a new release for the script in VIB form to address this issue.  You'll have to uninstall the package from ESXi before initiating the upgrade:

esxcli software vib remove --vibname=ghettoVCB

After the upgrade, you won't be able to reinstall the VIB, the same error will occur.

Manual Install

Ultimately, ghettoVCB is a shell script, so we just need to drop the files into a suitable location.  The VIB installs to /opt/ghettovcb, but as we're deploying the script by hand, we'll need to use a persistent data store.

You can download the entire zip from the repository, but we only need the ghettoVCB.sh script to perform the actual backups.  Assuming you have the httpClient firewall rule open, you can download the script directly from a shell session to where you like by running:

wget --no-check-certificate https://raw.githubusercontent.com/lamw/ghettoVCB/master/ghettoVCB.sh

You will then need to mark the script as executable:

chmod +x ghettoVCB.sh

Otherwise you configure it in the same way as previously - and for this I'd definitely recommend storing your configuration file on a persistent datastore.  You can of course, grab the example config in a similar way:

wget --no-check-certificate https://raw.githubusercontent.com/lamw/ghettoVCB/master/ghettoVCB.conf

VIB or not, I've got another shell script that I use to define the call to ghettoVCB, which contains the switches I want pass into the script, and then redirects the output to a log file, e.g:

vmfs/volumes/mystore/ghettoVCB.sh -g /vmfs/volumes/mystore/ghettoVCB.conf -f /vmfs/volumes/mystore/vms.conf >> /vmfs/volumes/mystore/ghettovcb.log

The advantage of using another script is we don't have to tamper with the main script if we want to decouple the script commands from the scheduler, which is a bit of a fiddle:

Scheduling

The running of your script can be schedule with cron, and while there isn't a crontab tool bundled by default, we can edit the file by hand.  You will need to edit the /var/spool/cron/crontabs/root file to add your schedule in, vi is available as a text editor on the shell for convenience.  I have my script set to run weekly at 11:30pm:

30  23  *  *  3  /vmfs/volumes/mystore/runbackup.sh

You will need to restart the cron service:

pkill crond
crond

 

I was updating a local copy of Microsoft BizTalk Server 2020 with cumulative update 4, when error struck and it failed to complete.  Fortunately for me, the log file the installer created was pretty useful, and I found this error sat near the end of the file:

[03/14/23 15:39:51] ExecuteCommand HRESULT=0x80040e2f
[03/14/23 15:39:51] The statement has been terminated. HRESULT=0x80040e2f
[03/14/23 15:39:51] SQL error: 01000 Native error code:  HRESULT=0x80040e2f
[03/14/23 15:39:51] Violation of UNIQUE KEY constraint 'UQ__JobData__F1AC1A950529D150'. Cannot insert duplicate key in object 'dbo.JobData'. The duplicate key value is (MessageBox_Message_Cleanup_BizTalkMsgBoxDb). HRESULT=0x80040e2f
[03/14/23 15:39:51] SQL error: 23000 Native error code:  HRESULT=0x80040e2f
[03/14/23 15:39:51] file.Close HRESULT=0
[03/14/23 15:39:51] session.Close HRESULT=0
[03/14/23 15:39:51] dataSource.Close HRESULT=0
[03/14/23 15:39:51] Failed to apply patch. HRESULT=0x80040e2f
[03/14/23 15:39:51] Abort distributed transaction.
[03/14/23 15:39:51] Failed to patch one or more BizTalk databases. See log for details. (HRESULT=0x80040e2f)
[03/14/23 15:39:51] The custom action returned -2147217873.

The table it's referring to is the BizTalkMsgBoxDb.dbo.JobData table, which contains a fairly boring list of some BizTalk jobs, I assume related to this database.  And when checking, sure enough, there is the entry the log file has complained about.  So I took a punt and truncated the table and ran the installer again and it completed without a hitch.  On checking back after patching, the table had been repopulated with the entries I had truncated.

There is a monumentally long SQL script that get generated to patch the tables, all with transaction wrappers to roll back if it has failed - but I do not have the time or the patience to trawl through that to see exactly where it went wrong.