VMware Cloud Community
SCX
Enthusiast
Enthusiast
‎12-13-2012 12:25 PM

SRM Reprotect Fails With "The Object Has already been deleted or has not been completely created"

There is an entry for this in the VMWare KB, here:

http://www.vmware.com/support/srm/srm-releasenotes-5-1-0.html

However, I just don't understand the workaround they describe:

If the primary site is still available:

  1. Clean up the recovery plan that failed.
  2. Start the reconfigure wizard for the group.
  3. Change the location of files on the datastore that has been disconnected and select the same datastore and folder locations.
  4. Reuse the existing disks and reconfigure the virtual machine.
  5. Wait for the group sync to finish. This sync uses existing disks and checks for data consistency .

I have a ticket open with them, but from past experience, I'm unlikely to get any joy.

Anybody know what on earth they are trying to say here? I guess the first step they mean check the "Force Cleanup" check box on the first dialog, since the "Cleanup" Link is not available as it stands.

But what the heck is the "reconfigure wizard for the group"?? What group? What wizard?

Thanks.

0 Kudos
2 Replies
mvalkanov
VMware Employee
VMware Employee
‎12-18-2012 05:47 AM

Hi,

The steps listed are about reconfiguring the replication of the individual VM (replication/consistency group) - if a datastore has changed its identity (managed object id) in vCenter Server, reconfiguring the replication will update the id values in VRMS database and will allow for the recovery plan to continue.

However, I guess that you might be experiencing a different issue than what is described in the release notes - it would be strange to see ManagedObjectNotFound error during reprotect, as SRM points VRMS to the original source VM when configuring the replication in the reverse direction and the datastore managed object id values are taken from the VM's current configuration.

Can you provide the SR number, so that I can take a look and try to help?

Regards,

Martin

SCX
Enthusiast
Enthusiast
‎12-18-2012 09:34 AM

Thanks for replying.

It seems that during a disaster failover, changing the IP of the ESX host is not a path supported by SRM, and this is what I was doing - basically, removing the host from vCenter, changing its IP and re-adding it.

This seriously messed up SRM to the point where reprotect was no longer an option and the published workaround was of little use.

The conclusion we came to is that all the VMs must be re-IP'ed to be on the same subnet that exists at the disaster site, and the ESX host and any runninng VMs there (vCenter etc), shouldn't have their IP changed.

In effect, this means that Primary and Disaster sites are not symmetrical (in terms of IP allocations anyway), and (at least in our case), since we have routers and software that work by IPs and IP ranges in many places, we will need an infrastucture redesign to accomodate this mode of failover.

A stretched VLAN would have been nice, but we don't have the network infrastucture or networking knowledge to support such a solution.

0 Kudos