Replica + hotadd, task sequence

[lohelle]

I see that when running replication and using proxy/hotadd, the snapshot of the replicated (source) VM is the last to be removed.

Sometimes the snapshot removal of the replica VM can take a long time (retetion policy). Would it not be better to remove the snapshot from the replica source VM first? This would reduce the snapshot commit time for that VM if it is quite busy.

There might be a reason for this sequence, but maybe you can explain?

[Gostev]

OK, if this is true, then it is embarrassing
Thank you for pointing this out.

[Gostev]

One other pending enhancement we have around replication is moving processing of retention policy to all replicas in the job to the end of the job. This should address the above issue as well.

[lohelle]

OK, if this is true, then it is embarrassing
Thank you for pointing this out.

It was not like this in v6.5
I checked some pre v7 logs.

[VladV]

I recently upgraded to v7 and I have noted this behavior which is different from v6.5. In may case, I have separate local replication jobs using NBD transport mode for each critical VM and it applies the retention policy before removing the production VM snapshot. In 6.5 the replication job first deleted the production vm snapshot and after that it proceeded to applying the retention policy.

Unfortunately this has a slight negative impact in our environment by increasing the snapshot size of the production vm and thus the time needed for committing increases.

Hope this gets fixed if possible.

Regards

[davidb1234]

Same. Hoping for a fix as soon as possible.

[foggy]

Yes, this is in the list of possible improvements. Thanks for the feedback.

[lohelle]

I tested a replica-job now with seeding (VMs restored from backup offsite, local to the replication destination).
I see that the source VM is "snapped" before the digest calculation. On very large VMs this can take quite a while, so I think the snapshot should happen AFTER the replica VM is prepared.

[veremin]

Hi, Lars. The digest calculation is a step where differences between source and target VM are being determined. It’s impossible to calculate them, if the state of virtual machine isn’t preserved. Thus, the snapshot of VM should be taken prior to “digest calculation”. Thanks.

[lohelle]

Is the source VM also read during the digest calculation? I was under the impression that only the destination VM had digest calculation. If only the destination have digest calculation, it should be possible to check if calculation is needed BEFORE the source VM is "snapped" ?

[veremin]

Is the source VM also read during the digest calculation?

Yep, in order to determine changes that have happened with the source VM since the latest replication run, source VM needs to be read again. Thanks.

[lohelle]

Yes, of course the source VM must be read during replication, but I do not think it needs to be read OR snapped before the first-run destination VM digest calculation is done.
This only happed the first time the job runs. Next time digest calculation is not needed (not in the same way anyways).

I did a test with a 1TB VM, and the digest calculation took 2 hours. The source VM was not read by the backup job during this time (after the snapshot was taken). The snapshot on the source VM grew quite a bit because of activity on that VM. On normal runs (after the first one) data is read almost immediately, but on the first run data is not read before the digest calculation of the seeded VM HDD is done

[veremin]

I’m not sure whether I follow you on that. As mentioned, digest calculation is the process of comparing two VMs; so, it’s necessary to read the source VM and snap it, as well, in order to preserve the state of it. And this’s exactly how our product works. Thanks.

[lohelle]

During digest calculation I ONLY see high reads on the target, not on the source. Are you SURE that the source VM is read during the initial digest calculation when seeding?

I'm pretty sure that only the destination VM is read (to calculate the digest). When the digest calculation of the destination VM disk is complete, THEN the changes between the source VM and the replica VM is transferred to the replica VM.

[veremin]

The digest calculation process includes reading source, though, this step takes place in the very end. You were correct that the snapshot is taken before the digests for target are calculated. Thus, there might be, indeed, space for some improvements in the future releases.

So, thanks for the valuable feedback; much appreciated.

[lohelle]

Even the best product in the world will have some room for improvements.