Extra verification of replica state?

[knuter]

Hello,

Is it possible to do an extra verification of a replica state when the original VM is powered off?
I know in theory it should be enough to run the replication job after the VM has been powered off, but I ran into an issue today where the replica VM did not appear to be in perfect sync with the original.

Some history:
First the VM(Win2008 & MSSQL2008) was replicated live with application aware processing and CBT.
Then it was powered off and the replication job was run once again. This time it failed on disk 2 with this error:
18.04.2013 01:44:00 :: Error: Client error: Soap fault. A specified parameter was not correct.
Unable to retrieve next block transmission command. Number of already processed blocks: [7129].
No biggie I thought and selected Retry and it went successful on that try.
All green so I failed over to the replica VM (We're moving from one datacenter to another)
The replica VM booted, but after a while we discovered that a couple of the MSSQL databases were corrupt.

We've restored the databases so everything is up and running again. On the original VM I disconnected the Network card and booted it. All databases are fine, no errors.
So I'm scratching my head here about what has happened...

What I wish for is some way to do an extra verification between the original VM and the replica VM while they're both powered off. Have anyone done that? If so, please share

[knuter]

Had a minor incident again.
First replication while original VM were running. Powered off and ran the replication job again. When it finished I did a failover.
When the replica VM when started, Windows prompted to run chkdsk. No errors found. Powered off the replica and did "undo failover".
Ran the replication job again. CBT showed 0 changes. Created a new replication job with the old replica as seed and ran the job. Finished successful.
Did a fail over again, and Windows prompted to run chkdsk again. No errors found. Powered off and did undo failover again.
Powered on the original VM, no prompting of chkdsk during boot.

Have anyone else experienced chkdsk having to run when booting a replica but not on the original VM? Could the VM itself somehow detect that it's booting on a different ESXi host and storage and therefore trigger a chkdsk?

[foggy]

Probably, this is expected. From OS perspective, the VM did not shutdown normally as it was snapshotted from a running state during job initial run. Not sure whether the incremental run against powered off VM has to change this behavior.

[knuter]

FYI, I opened a case (00205012) and it's escalated to the developers.
A workaround is to first do a backup, restore and use the restored VM as a seed for the replication job.

[fredbloggs]

Sorry to bring up an old thread, but i'm experiencing this same disparity between source and target VMs. I have tried seeding with backup and that has generally been successful for those replicas that happen soon after but give it a few increments (<10 usually) they are not any better than others.

I have also found that it appears to be more successful if I don't turn off the source VM and then test the target VM but that's not suitable for several of my servers that I wish to do this for.

I have also found that in a minority of cases does it need to do a chkdsk on boot, but ~70% of the time if I run a manual chkdsk on a replicated target VM it reports chkdsk errors yet the source doesn't. I have had only one disparity like this with backup/restore (whether the source is on or off)

I have tried with VSS enabled and not to create the initial replica (as well as backup/restore mentioned above)

I have been in the progress of migrating off of one SAN to another, was originally expecting this to take a few evenings, it has so far taken about 4 weeks since I have been reduced to replicating single VMs at a time, testing for chkdsk disparity between systems (remember, this is powered off VMs so no VSS, quiescing or anything issues, should simply be an identical copy of the VM disk (i believe))

i have a ticket open with support (been escalated) though the 24x7 escalated support doesn't seem to start until 4PM my time so that has been very slow going and they are asking for the same information that their initial support gathered (which was quite close to my timezone) and I really don't have the time to spend several hours repeating the above steps.