CDP Replication of VMWare Encrypted Servers

[BoKTC]

Hi all,

Has anybody tried using CDP Replication with VMWare Encrypted VMs yet?

Our experience is that everything works until the moment you attempt failback, at which point Veeam instructs VMWare to decrypt the VM in production prior to commencing the copy back from the replica. Has anybody else experienced this? We're using Veeam 12 with vSphere 7.0U3

We've opened a support case with the vendor, prior to going straight to Veeam, but would appreciate knowing if anyone else has come across this.

[veremin]

Have already contacted our support team? If yes, can you provide us with the ticket number? If not, can you kindly open one - the R&D team would like to check the issue further?

Thanks!

[BoKTC]

It's currently with our vendor's support team at this stage.

[veremin]

And by vendor, do you refer to the key provider in this? If after the investigation the issue persists, don't hesitate to reach our support team. Thanks!

[BoKTC]

Hi Veremin,

So we're using the VMWare Native Key Provider for our VMWare Encryption.

It would be useful if possible to get a process flow for how Veeam deals with an encrypted VM during CDP.

For example, when we set up CDP for an encrypted VM, the replica is pointed at an encrypted storage policy during datastore selection and the replica is encrypted at the same level as the source machine, however during failback, Veeam triggers a decryption of the source VM prior to copying back the restore point. The copy back will occur even if the decryption fails due to lack of space, but the entire disk will then be copied back rather than a differential copy of changes. Once the failback is complete, we have to manually re-encrypt the server to regain its original state.

[veremin]

Hi, Ash,

We are going to run a few tests internally to confirm the storage policy selection logic applied during failback to the original location. I will post the results of our findings and cover missing pieces, if any.

Thanks!

[veremin]

We failed to confirm your findings regarding the storage policy selection algorithm used during failback to the original location. Our tests showed that the original storage policy was selected during this operation, which means if the original VM was subscribed to the encrypted policy, its replica failed back to the original location should have the same encrypted policy applied.

I believe you've already created a support ticket with us, but my understanding is that it currently misses the failback debug log (the support engineer should request it briefly).

The R&D team will assist with the investigation process.

Thanks!

[BoKTC]

Well, R&D provided a private fix for this issue which I've applied this evening and...

...it didn't work:

Our test virtual machine once again had its disk decrypted during failback in the "Preparing original VM" step.

I'm going to remove the replica and recreate the CDP policy to see if the fix requires this (although this wasn't specified) but I'm not hopeful.

[veremin]

I see that you've confirmed in the ticket that encryption was preserved during failback on recreated replicas. So seems like the original issue is finally solved. Thanks for raising this!

[BoKTC]

Hi,

I can indeed confirm that the encryption issue has been resolved - I've tested it today on one of our larger encrypted VMs with no decryption being observed.

Thanks for supporting this one.

[veremin]

You are welcome. Thanks for coming back and updating the topic!