Advice on updating ESXi hosts running Veeam CDP jobs

[kevin.boddy]

Hi,

We are replicating 230x VMs with Veeam CDP.
What is Veeam's advice around how we should update our destination ESXi hosts?
Reason I am asking is ever time we need to patch our destination hosts, a portion of the CDP VM replications break and the long term retention points start timing out during creation.
The only way I can fix this is by creating the VMs CDP replication in a new job.

When we are patching our destination hosts, which happens over about 2x days, I leave the CDP jobs running and just let DRS handle the vMotion of the CDP replicas.
Obviously I want to minimise replica downtime as the RPO is 30 minutes on the VMs, so I don't particularly want to stop all the jobs for 2x days.

Any advice would be appreciated.

#08151153

Thanks
Kevin

[kevin.boddy]

So it seems like me following a normal update procedure of putting ESXi hosts into maintenance mode and applying updates and then rebooting like normal isn't causing my problem with Veeam CDP long term retention points.

The issue is the iofilterd-veecdp service.

This error is reported in the VBR I_O_filter_deployment.log file
Thumbprint [5625AECBC68E8EECC58B960856AAC30AC90A4D36] does not match the certificate’s thumbprint [2BEDC62E587234BA40DCEB071BA40A455EC7DD29] (System.Exception)
I have to restart the iofilterd-veecdp service manually on the ESXi host to fix this.

The problem is doing the normal manage io filters on the vCenter on the VBR server and running through that wizard, it checks all the host, reconfigures them apparently, and says everything is fine when it's clearly not.
The CDP job also doesn't report an issue with a certificate mismatch, it just says long term retention creation timeout.

[david.domask]

Hi Kevin,

I'm not aware of any specific steps / requirements for minor updates to the ESXi hosts when CDP is in play, and your strategy seems pretty normal.

Are you doing major version updates on the ESXi hosts or minor patches? (can you maybe list the versions before / after just for avoidance of confusion)

From the case, it looks like the root cause was a certificate change and restarting the CDP daemon looks to have resolved this; however, I do agree with your latest statement that this type of error should be returned as the actual failing reason instead of a generic timeout message, but it's not clear to me why going through the CDP filter wizard did not detect this and handle it.

Please continue with Support on the case regarding the remaining questions about why the error didn't show more clearly / why the CDP filter wizard didn't catch the certificate change.