VMware Cloud Community
toobulkeh
Contributor
Contributor
Jump to solution

DR-IP-Customizer Customization Specification Fails on Recovery Plan

I'm having problems using the dr-ip-customization tool provided with SRM. Using SRM 4.0 and vCenter Server 4.0, the generate command generates a pretty blank CSV file with only shadow vm names, vm names, and one 0 adapter ID per vm, while each VM really has multiple adapters, and complex information that should be filled out in the rest of the table.

VM ID, VM Name, Adapter ID, MAC Address, DNS Domain, Net BIOS, Primary WINS, Secondary WINS, IP Address, Subnet Mask, Gateway(s), DNS Server(s), DNS Suffix(es)

shadow-vm-1111,vm-1111,0,,,,,,,,,,

shadow-vm-2222,vm-2222,0,,,,,,,,,,

shadow-vm-3333,vm-3333,0,,,,,,,,,,

shadow-vm-4444,vm-4444,0,,,,,,,,,,

I then populate the table and run the create/recreate command back in, which succeedes in creating customization specifications, but the recovery plan still runs and fails. My populated csv looks more like:

VM ID, VM Name, Adapter ID, MAC Address, DNS Domain, Net BIOS, Primary WINS, Secondary WINS, IP Address, Subnet Mask, Gateway(s), DNS Server(s), DNS Suffix(es)

shadow-vm-1111,vm-1111,0,,,,,,,,,,

shadow-vm-1111,vm-1111,1,00:50:56:38:08:11,,,,,10.10.10.10,,,,

shadow-vm-1111,vm-1111,2,00:50:56:13:08:11,,,,,11.11.11.11,255.255.255.0,11.11.11.253,,

..... (continues for all 4 shadow VMs)

The run fails on step 5. "Recover Normal Priority VMs..." with Error: Cannot complete customization.

I am not running a test of a run, but am executing the run, because I'm using EMC's SRDF Adapter which requires extra licenses / installs of VSI plugin and TimeFinder devices to perform the test.

So is there something wrong with my formatting or information? Shouldn't the generate tool spit out a more complete csv?I have never seen an example with multiple adapters, does that not work?

Thanks!

0 Kudos
1 Solution

Accepted Solutions
mal_michael
Commander
Commander
Jump to solution

And if you do a rescan of HBAs, VMs are not getting status of orphand or inaccessible?

View solution in original post

0 Kudos
10 Replies
mal_michael
Commander
Commander
Jump to solution

1. MAC address is not required.

2. What is guest OS of your VMs?

0 Kudos
toobulkeh
Contributor
Contributor
Jump to solution

The SRM Admin 4.0 document said that when using multiple adapters the mac address was required to reference the proper adapter. All the VMs are also set to manual MAC addresses.

These VMs are linux based, RHEL I believe.

0 Kudos
mal_michael
Commander
Commander
Jump to solution

1. OK. If you have multiple NICs, SRM looks on PCI slot number of the NIC, so, adapter 1 on the CSV relates to the NIC with lowest PCI slot number and so on. But if you want to be sure that customization is applied to the correct NIC, you can specify the MAC.

2. From the admin guide:

For any non-zero adapter ID that is not a DHCP client:

You must specify values for IP Address, Subnet Mask, Gateway(s), and DNS Server(s) unless

global values for these properties exist (in the row for Adapter ID zero for that VM ID).

I think this is your problem

toobulkeh
Contributor
Contributor
Jump to solution

that's helpful. I'll give it a shot and send an update.

Is there a reason why this wasn't automatically populated with generate? An empty CSV is going to be hell when we have to test 300+ vms...

0 Kudos
toobulkeh
Contributor
Contributor
Jump to solution

Oh and another comment of note, I'm still at the failback stage where you have to clear the old orphaned VMs from the original protected site, and sometimes they won't delete and will take hours to timeout. The VMs just sit there like they work fine and remove from inventory or delete from disk doesn't work. Is there any way to mark these as orphaned faster? Maybe without restarting vCenter?

0 Kudos
mal_michael
Commander
Commander
Jump to solution

This is by design. I agree with you completely and hope VMware will change this in next releases.

0 Kudos
mal_michael
Commander
Commander
Jump to solution

Do you try to unregister the VMs after you have detached the LUNs from the ESX hosts?

toobulkeh
Contributor
Contributor
Jump to solution

The LUNs are already listed as empty. Should I go in and manually detach them from the ESX host (bypassing vCenter?) or are you suggesting something different? EMC SRA simply flips the Read/Write to Write Disabled when converting between a RDF1 to RDF2 device types. It does nothing to the mapping, so vCenter simply sees these luns as invalid datastores.

0 Kudos
mal_michael
Commander
Commander
Jump to solution

And if you do a rescan of HBAs, VMs are not getting status of orphand or inaccessible?

0 Kudos
sselvara09
Contributor
Contributor
Jump to solution

Thanks Michael, I've found the info what i'm looking for.

-Sumathi

0 Kudos