Posted on Leave a comment

Vmware Host returns esxupdate error code:15 – Check update manager log

I tried to update a VMware host through update manager and I got the below error through stage and remediation.

VMware indicates that:

This issue occurs if the /locker/ folder contains too many files aside from the /locker/packages (or /store/packages) folder. Remediation cannot happen as the disk does not have enough space.

/locker partition is the local Datastore of the host and in my case did not contain a lot of data except from the directory of packages.

The solution for this error was to remediate less updates and not all of them once. For example I could remediate 28 patches, but I performed that in two waves 14 on each iteration.

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

Posted on 2 Comments

The checksum from the provided manifest file do not match the content of file .ovf

I have faced the below issue by trying to deploy an .ovf exported VM (6.5 build 10964411 vCenter)

selected files to deploy

After validation, the below error appears.

error while import

The solution is to upload/import the .ovf from a single host UI and not vCenter server and then migrate your VM in your vApp/host/cluster needed.

Posted on Leave a comment

Veeam Backup fails with log message: CBT Data is Invalid

Having your backup jobs fail is really a frustrating experience. 99,5% of the time, i’m experiencing successful backups, either over TSM, or Veeam Backup.

However, there were more than a handful of times that the CBT (Change Block Tracking) stopped working, generally causing backup jobs to fail.

The message listed in the Action log is the following:

CBT data is invalid, failing over to legacy incremental backup. No action is required, next job run should start using CBT again.
If CBT data remains invalid follow KB1113 to perform CBT reset. Usual cause is power loss.

I’ve tried to narrow the reasons this happens, to mostly being Datastore capacity outage or the speed of snapshots being removed during the backup process.

Luckily, there is a solution and it lurks in the VMWare KB2139574 (Resetting Changed Block Tracking for VMware vSphere virtual machines) .

You can generally follow one of the two recommended actions according to VMWare:

  • Power off the VM and reset CBT
  • Run the provided script to reset CBT on all VMs, which uses a snapshot method to save having to power the VMs off.

Personally, although i have tried both actions, i prefer the second approach, as most of the virtual Infrastructures contain VMs that are not easy to power off, or have different maintenance windows.

In any case, after reattempting to execute the Veeam backup job, the error is no longer there, and Change Block Tracking is back in use.