When performing storage vMotion on _replica VM, I get consolidation is required warning in VMware?

[cerberus]

Case #07565302

Hi all,

We use VBR 12 to back up our VMware VMs to disk, and to also replicate to a disaster recovery site. The replication job is set to keep 5 restore points for the _replica VMs.

At the DR site, when I do a storage vMotion of the _replica VM from one datastore to another, I get the "Virtual machine disks consolidation is needed" and "Consolidation is required" alarms on the VM.

What does one need to do in this case, I am pretty sure we're supposed to leave the handling of the _replica snapshots (restore points) to Veeam and not attempt to consolidate manually?

I have to migrate all _replica VMs from one datastore to another to move to a new SAN, and want to avoid losing any replication progress, or having to re-replicate VMs, what is the supported method to storage vMotion these _replicas?

[david.domask]

Hi Mirza,

I tried to reproduce on one of my replicas with a few restore points (snapshots) -- initially it flagged for consolidation, but after the next backup run (which ran as normal incremental), the consolidation warning was removed.

Few questions quick:

1. For the replica jobs, are you targeting a cluster or an individual host?
2. Are the datastores of the same type? (VMFS, NFS, etc)

Storage vMotion can work with snapshots since vSphere 5.x, so I'm not sure at the moment why the consolidation alert triggers and seems to self-resolve in my test.

Allow me a bit of time to research this and I'll update the topic once I have more information.

[cerberus]

Hi David,

Good that you are able to reproduce it, I observed the same results as you, initially it was flagged for consolidation alarm in vCenter right after I did the storage vMotion. I also confirmed that the _replica disks were not mapped to the proxy VM or anything crazy like that.

After the backups and replication ran last night, the "Consolidation is required" warning message is no longer there this morning.

Code: Select all

6:28:58 PM	Replicating restore point 1/9/2025 6:15:54 PM from backup repository R760-SSD 	
6:29:38 PM	Queued for processing at 1/9/2025 6:29:38 PM 	
6:29:38 PM	Required backup infrastructure resources have been assigned 	02:02:24
8:32:06 PM	VM processing started at 1/9/2025 8:32:06 PM 	
8:32:06 PM	VM size: 100 GB (57.5 GB used) 	
8:32:10 PM	Discovering replica VM 	00:44
8:33:05 PM	Preparing replica VM 	00:01
8:33:07 PM	Processing configuration 	00:11
8:33:20 PM	Creating helper snapshot 	00:01
8:33:26 PM	Using target proxy DR-VBRProxy01.xxx.xxx.com for disk Hard disk 1 [hotadd] 	
8:34:14 PM	Calculating digests for Hard disk 1 (100 GB) 	03:10
8:37:26 PM	Hard disk 1 (100 GB) 6.8 GB read at 35 MB/s	03:23
8:41:06 PM	Deleting helper snapshot 	00:06
8:41:15 PM	Finalizing 	00:00
8:41:20 PM	Busy: Source 0% > Proxy 4% > Network 63% > Target 62% 	
8:41:20 PM	Primary bottleneck: Network 	
8:41:20 PM	Network traffic verification detected no corrupted blocks 	
8:41:20 PM	Processing finished at 1/9/2025 8:41:20 PM

The replication job ran clean as well as you can see from the logs, there was no warning for the _replica VM.

We are on VBR 12 and vSphere 8.0.2, the replication job targets the Cluster. This is on a VMFS6 datastore backed by a FC SAN.

I guess my concern is, is this normal? I ask because I need to storage vMotion all of these _replicas from one datastore to another (new SAN); and I was concerned with the _replica integrity when I did my test run, because of the resulting "needs consolidate" message and the VM getting that "warning" icon in vCenter

[david.domask]

Discussed internally -- sVmotion of the replica is typically fine. Historically there have been a few instances where duplicate VM folders were made on the target datastore and/or vmx/vmxf files failed to copy, but these were exceptions.

The consolidation request is very strange, and I had the same results as you. My colleagues from RND also saw the same behavior, so it looks to be a false-alert on the vCenter side. In quick testing, the consolidation procedure doesn't seem to change anything with regards to the VM files, so looks to be an issue with vCenter database (some wrong flag likely after the sVmotion). In my tests, simply running the replica job after the sVmotion looked to resolve the issue as ell.

I would advise continue testing first with low-priority replicas to migrate and test a quick failover (you can just undo the failover afterwards), but I don't expect any challenges.

[cerberus]

Thanks for confirming, I was able to clone the _replica and boot it up without issues, does not seem to affect the integrity of the VM itself; we will continue with our mass sVmotion of the _replicas.