SRM Lab - No Array Pair in Protection Group

Well, this was a weird one, I spent a day labbing an SRM configuration and after fighting my way through certificates and domain controller issues I ended up not being able to create a protection group. This taken from the SRM Logs:

2013-09-06T13:30:09.385+01:00 [05420 warning 'DatastoreGroupManager' opID=33174abf] No read-write devices found for array pair 'array-pair-2038'
2013-09-06T13:30:09.385+01:00 [05420 verbose 'DatastoreGroupManager' opID=33174abf] Recomputed datastore groups for array pair 'array-pair-2038': 0 replicated datastores, 0 replicated RDMs, 0 free devices, 0 datastore groups

It's just not detecting anything it can work with even though everything looks fine and is replicating at the VSA end...!

I got talking to a great guy in HP Support about it and he came back and said to check the IQN for upper case characters. In the HP StoreVirtual Centralized Management Console I had added the VSA's using upper case characters and this was reflected in the IQN seen in VMware.

I unexported the volumes, deleted the servers in the HP console and recreated them, refreshed the ESX iSCSI config and rebooted the nested ESXi hosts for good measure. The screen shots below show what the configuration I got working looks like and how it SHOULD have been configured!

 

There should be no upper case in the Name shown below:

 

 

Then after rescanning the SRA and Devices I was able to create my first protection group (My issue was I was shown NO array pairs to choose from):

So that's one I'll remember! Thanks to HP Support for spotting my mistake!

Mike

Upgrading DC to 2012 throws VMware SSO a loop

Hi Folks,

Well, I decided to prep my Lab for vSphere 5.5 and get server 2012 and sql 2012 out there so I can have fun figuring out where everything is moved to! I just started with my single Lab DC which was on Server 2008 R2 and installed a second DC with Server 2012. Darn, I just remembered 2012 R2 is around the corner, could've waited, oh well! I know there are some weird things about changing the name of your DC affecting vCenter and you've to edit the database but I wanted to basically replace my Lab DC with a new one and end up keeping the same IP and Name.

Note: None of this may be supported so follow at your own risk, this is my Lab, not a Production environment!

My problem was when I booted up my full lab and the new DC was running away fine with the old name and IP, the vCenter Service on my two linked mode vCenter VMs would not start. The vpxd.log showed the following errors:

2013-09-06T09:11:58.472+01:00 [04896 warning 'Default'] Warning, existence of group "LAB\Domain Admins" unknown, permission may not be effective until it is resolved.
2013-09-06T09:11:58.534+01:00 [04896 error 'Default'] The group account "LAB\Domain Admins" could not be successfully resolved.  Check network connectivity to domain controllers and domain membership.  Users may not be able to log in until connectivity is restored.

I also got netlogon errors in the system event logs. To start with I thought the vCenter VMs were having some difficulty talking to the new DC even though it is using the same name and IP address. I use netdom to rejoin them to the domain:

netdom.exe remove IEDUBDC1VC01 /Domain:lab.local /userd:lab\administrator /passwordd:XXXXXXX

netdom.exe join IEDUBDC1VC01 /Domain:lab.local /userd:lab\administrator /passwordd:XXXXXXX

I was able to enter both commands one after the other and then reboot saving some time.
This fixed the logon errors but the vCenter service still had the same issue.

So maybe SSO was the issue - the errors above were wrapped by SSO entries:
[SSO][SsoAdminFacadeImpl]'] [FindGroup]

I found a great post here that would deal with the issue:
http://www.gabesvirtualworld.com/vcenter-sso-changes-when-demoting-domain-controller/
except when I went to launch the web client this is what I got:

 

Catch 22?!! Looked like it. I knew SSO had command line options but I'd never used them. I was able to list the current SSO configuration and from there tried removing and re-adding my Domain source, once I'd done that vCenter service started up fine. Here are the commands:

Note: the account to use appears to be just "admin", I'd tried admin@System-Domain and other variations before I figured this out!

 

This lists the current configuration:

 

C:\Program Files\VMware\Infrastructure\SSOServer\utils>rsautil manage-identity-sources -a list

Super Administrator's name: admin
Super Administrator's Password: ********
External identity sources:

Name: lab.local

ID: ims.8dd6788d2b0aa8c05a7226e3edcef61b
Type: Active Directory
Primary URL: ldaps://LABDC.lab.local:3269
Failover URL:
Domain: lab.local
Alias: LAB
Principal Base DN: DC=lab,DC=local
Group Base DN: DC=lab,DC=local

Successfully executed action: 'list'

 

This removes the current configuration, copy and paste the ID from the output above:

 

C:\Program Files\VMware\Infrastructure\SSOServer\utils>rsautil manage-identity-sources -a delete

Super Administrator's name: admin
Super Administrator's Password: ********
ID of the identity source to delete. Use list action to retrieve the ID: ims.8dd
6788d2b0aa8c05a7226e3edcef61b
Successfully executed action: 'delete'

 

This one adds back the Domain information, I've used the domain rather than specify a particular domain controller:

 

C:\Program Files\VMware\Infrastructure\SSOServer\utils>rsautil manage-identity-sources -a create

Super Administrator's name: admin
Super Administrator's Password: ********
Primary URL: ldap://lab.local
Secondary failover URL:
Domain name: lab.local
Domain alias: LAB
Base DN for users: cn=Users,dc=lab,dc=local
Base DN for groups: cn=Users,dc=lab,dc=local
LDAP administrative account user (read operations): lab\administrator
LDAP administrative account password: ********
Identity Source added. ID: ims.32fa4eb12b0aa8c0073ec51929b46c33
Successfully executed action: 'create'

 

This confirms the new settings:

 

C:\Program Files\VMware\Infrastructure\SSOServer\utils>rsautil manage-identity-sources -a list

Super Administrator's name: admin
Super Administrator's Password: ********
External identity sources:

Name: lab.local

ID: ims.32fa4eb12b0aa8c0073ec51929b46c33
Type: Active Directory
Primary URL: ldap://lab.local
Failover URL:
Domain: lab.local
Alias: LAB
Principal Base DN: cn=Users,dc=lab,dc=local
Group Base DN: cn=Users,dc=lab,dc=local

Successfully executed action: 'list'

 

vCenter functioned perfectly at this point and the service loaded up fine. I had to manually reselect the Update Manager service account and re-enter the password but then that service worked fine also, even before the SSO steps above.

 

I'm looking forward to the new overhaul of SSO in 5.5, hoping it makes life a little easier but we'll see! This might help those of you stuck with a Wintel team changing AD on you without notification and the next time you bounce vCenter you're stuck! Make sure you warn them about how VMware components are tied to AD intimately so they give you plenty of time to plan ahead and test after the upgrade.