cswaters1
Contributor
Contributor

Protection Group missing VMs

Hi,

I've successfully completed a failover without any issues, I'm now at the point where I start the failback procedure.

  1. I've unregistered the protected VMs at the old protection site,

  2. I've removed the protection groups that have been implemented at the old protection site,

  3. I've removed the placeholder VMs at the local non-replicated LUNs at the old recovery site,

  4. I've reconfigured my array (CLARiiON with MirrorView/S),

  5. I rescan the array and all disks are present and accounted for,

  6. My Invetory Mappings are reversed,

  7. I now come to create the protection groups, but some of the VMs are not listed in the datastore group, they're just missing...

Any suggestions??, I have about 2-3 VMs which are never visible when I create the protection group, they look fine, they are on the correct Datastores, they don't have any CD-ROMs attached, nothing is obviously wrong... I've tried rebooting/restarting the VC / SRM servers/services but no change.

Can anyone suggest a resolution?

Thanks,

Craig.

Craig Waters | vExpert | Melbourne VMware User Group Leader | website: craigwaters.org | twitter: @cswaters1
0 Kudos
4 Replies
Smoggy
VMware Employee
VMware Employee

Hi Craig,

ok so at the site where the mirrorview primary image should now be (where you failed over to) if you login to the SRM server at that site and now configure the mirrorview SRA via the "Array Config" wizard what do you see in the "Review Replicated Datastores" screen at the end of that wizard?

What you should see assuming the mirrorview replication is now successfully replicating back the other way is the datastore groups that used to live at your other site, these will all probably be prefixed snap-xxxx-oldvmfsname but they should be there once you've clicked the "Rescan Arrays" button in that view. Sometimes you need to press the button, exit the wizard and then navigate back to the same screen before you will see them. This is a UI bug I think.

The only step in your post that concerns me is that you say you've removed from inventory the placeholder VM's. That should not be necessary as the placeholder VM's are no longer placeholders after a failover they are the real VM's as during the failover SRM will unregister the placeholder and reregister the actual VM in its place. The only VM's you remove from inventory are the original VM's left behind at the original protected site.

SRM queries VC for all VM objects, if you've accidentally removed VM's from the vCenter inventory that were actually real VMs and NOT placeholders then these VM's won't appear in the datastore groups anymore, when you create a protection group and select available datastore groups the list of VM's that appear in the lower pane of that wizard are the only ones SRM knows about. So it sounds like your saying those lists are shorter than you expected which could be because you removed them from VC.

hope this helps,

Lee Dilworth

cswaters1
Contributor
Contributor

Hi Lee,

Apologies for the delayed response been attending the vForum conference over in Sydney.

I'll try and make my question a bit clearer...

So I've sucessfully completed a failover, no problems everyone is happy Smiley Happy

I've completed the reconfiguration steps ready for failback and all SAN related configuration looks fine.

My issue is that there are a couple of VMs which exist in the recover site (they failed over fine) that when I create the protection group at the old recovery site / new protection site are missing, other VMs that use the same datastores / storage are discovered when I create the protection group?!?

I just don't understand it...

Can someone make any suggestions on how to fix these missing VMs, is it something to do with missing information in the .vmx ?

Thanks in advance for your help,

Craig.

Craig Waters | vExpert | Melbourne VMware User Group Leader | website: craigwaters.org | twitter: @cswaters1
0 Kudos
cswaters1
Contributor
Contributor

Just to give everyone a heads up...

The problem was related to .vmx file.

I had problems with these VMs originally as they had incorrect settings in the .vmx file (workingDir = needed to be changed to "." ).

After going through the vmware-dr logs (should have got off my arse and done this in the first place instead of just throwing out a question before doing some research) Smiley Happy

I noticed errors with the VM being discovered during the add VM to inventory process.

There errors were again related to the contents of the .vmx file (something about suspend.Directory not being a valid vmfs volume). So to fix it I did the following:

  1. I just removed the VM from inventory,

  2. renamed the folder where the vmx file resides,

  3. created a new VM with the same name and a new folder on the same Datastore,

  4. moved all the files to the new VM folder (except .vmx, vmsd, vmxf)

  5. Added the VM into inventory,

  6. added the disks to the correct scsi id's

  7. Bought up the VM and confirmed it was all good,

  8. deleted the renamed VM folder on the datastore.

At this point SRM found the new VM and I was able to protect it like all other VMs in the protection group.

Thanks for watching this space and thanks Lee for contributing!

Craig.

Craig Waters | vExpert | Melbourne VMware User Group Leader | website: craigwaters.org | twitter: @cswaters1
0 Kudos
Smoggy
VMware Employee
VMware Employee

sorry I only just got back online today!!! but glad to see you got it resolved...my next request would have been "send me the log" but you looked at it yourself Smiley Happy

best regards,

Lee

0 Kudos