Some unanswered questions

I have some questions about SRM which I've yet to work out. I'm hoping that someone from the SRM Team will be able to answer them:

Port 80

The installer ask to speak to VC on port 80. You cannot type 443 in the installer - after the install of SRM the system communicates to VC on 443. So why port 80 in the installation

Certificates

What is the correct way to setup SRM with internally trusted certificates?

SQL Permissions

It seems that SRM follows VC. Windows Authentication is only support if you run SQL locally, SQL Authentication is required for external DBs. Fine. But are the minimum SQL permissions on DB for the installation. DB_OWNER only

Parallel Per Host

In the Admin guide what is “parallel per host” order in the Normal/Low of Recovery Plan - and how does this play against the order buttons

Array Managers Repair Button

What is the purpose of Array Managers Repair button

Thanks!

Mike

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
19 Replies
admin
Immortal
Immortal

Sorry Mike, I cannot answer all of your questions. But I can answer one (maybe two) of them! The array manager repair button is for when the protected site (where normal array actives occur) is not available and you MUST do array reconfiguration stuff. The parallel by host is complicated. The order of bringing VM's back online is interesting. Normal and Low priority protection groups will be started one VM per ESX host - and if recovering to a resource pool it may be more than one ESX host. High priority VM's will be started one at a time 9serially). No matter how many ESX servers in the resource pool.

Hope that this helps!

Michael

0 Kudos

Sorry Mike, I cannot answer all of your questions. But I can answer one (maybe two) of them! The array manager repair button is for when the protected site (where normal array actives occur) is not available and you MUST do array reconfiguration stuff. The parallel by host is complicated. The order of bringing VM's back online is interesting. Normal and Low priority protection groups will be started one VM per ESX host - and if recovering to a resource pool it may be more than one ESX host. High priority VM's will be started one at a time 9serially). No matter how many ESX servers in the resource pool.

Hope that this helps!

Michael

Can I just clarify your answers?

I can understand that the Protected Site Array will not be available. But what do you actually mean by "you MUST do array reconfiguration stuff". What sort of reconfiguration. I'm sorry I still don't really understand what it "repairs" as such...

Now, I understand the "parallel host" option. I thought it meant this. Just start these VMs as quickly as possible. BUT, doesn't that rather negate the UP/DOWN order buttons in the plan - so I can make sure VM1, starts before VM2. If this is true - it means I can ONLY use "high" priority to rigiously control the start-up order. If this is a case I think the UP/DOWN buttons should be grey'd out - its gives the impression that order is obeyed... which isn't strictly true - these VMs could be started simulatanously. Is that a far critique?

Regards

Mike

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
admin
Immortal
Immortal

Hi Mike,

Sorry for not being more clear. I cannot think of a use case for the repair button. And what I gave you was, for the most part, what I got when I asked the guys who know. But lets just say you wish to see if newly added VM's, or perhaps a new lun in a data store was visable. You could normally goto the protected site and run the array config, but for whatever reason you cannot connect to the protected site, you could use the repair array managers button to start the array config utility to look at the array config.

Again, sorry not more clear, but hopefully someone else here might be able to provide better info. I have checked the documentation, and I have stared hard at it and cannot think of something better!

As for the start order. You are correct. I in fact just tested it. I had three VM's at Normal priority. They were being recovered at a resource pool that had two ESX hosts in it. During the test failover two of the VM's, one per ESX host started at the same time. In fact to the second.

I will ask around about this start order thing and answer you here. Great catch. I never thought of this in all my playing!

Michael

0 Kudos
admin
Immortal
Immortal

Hi Mike,

Here are some more answers:

Port 80:

Even though SRM uses SSL when it communicates to VC, it does not use port 443. SRM establishes a TCP connection to port 80, then uses an HTTP CONNECT request to establish a tunnel to the VC server, then does an SSL handshake with VC over that tunneled connection. The SRM installation enforces these semantics.

DB Permissions:

You should be able to use Windows Authentication to run the SQL Server DB remotely. However, both machines must be part of the same Domain. I believe that the testing we did included the use of Windows Authentication.

For SQL Server, the SRM DB user does not need the DB_OWNER permissions. As long as the schema has the same name as the username, and is the default schema for that user, and is owned by that user, then you're OK.

Is that clear?

Arturo

0 Kudos
admin
Immortal
Immortal

WRT the host ordering, you are correct in saying that there is no guarantee of ordering within the normal and low priority VMs group. However, SRM does go through the list in order. Although the first N VMs are started in parrallel (i.e., where N is the number of ESX hosts), SRM never powers on the N+1 VM before it starts to power on the previous N. In addition, the up/down button is the only mechanism in to move VMs into and out of the various groups within the recovery plan.

0 Kudos
admin
Immortal
Immortal

One more thing...

This information has been revised for the next edition

of the SRM Admin Guide. Here's an excerpt from that

revision.

Repair Array Managers

If you need to edit array manager details when the

protected site is not accessible, use the Repair

Array Managers function. (If the protected site is

accessible, you can accomplish the same thing by

following the procedures in "Configure Array

Managers" on page 50.)

To repair array managers:

In the Inventory, click Recovery Plans.

In the Commands area of the Summary tab, click

Repair Array Managers. This opens open the Recovery

Site Array Managers page of the Configure Array

Managers window. Use the Add, Remove, or Edit

buttons to modify array manager information for the

protected site.Repair Array Managers

0 Kudos

Hi Mike,

Here are some more answers:

Port 80:

Even though SRM uses SSL when it communicates to VC, it does not use port 443. SRM establishes a TCP connection to port 80, then uses an HTTP CONNECT request to establish a tunnel to the VC server, then does an SSL handshake with VC over that tunneled connection. The SRM installation enforces these semantics.

DB Permissions:

You should be able to use Windows Authentication to run the SQL Server DB remotely. However, both machines must be part of the same Domain. I believe that the testing we did included the use of Windows Authentication.

For SQL Server, the SRM DB user does not need the DB_OWNER permissions. As long as the schema has the same name as the username, and is the default schema for that user, and is owned by that user, then you're OK.

Is that clear?

Arturo

Thanks for this - very useful answers!

One thing that thru me is the statement "schema has the same name as the username, and is the default schema for that user, and is owned by that user, then you're OK.". I'm no SQL person. I understand that each DB has its own schema (yes?), but I'm not sure how it is named, and how that schema would be made match a username - and grant ownership. Is that more secure than DB_OWNER, i know how to set that...

Regards

Mike

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
michaeltsa
Contributor
Contributor

In this case is that the "Array Manager" muct be working and reconized for SRM to be fully function? Becasue I can't reate the "Protection Groups".

0 Kudos
admin
Immortal
Immortal

Yes, you need the array configured so that your protected datastore is seen, and you need VM's on it as well. Then you can create your Protection Groups.

0 Kudos
admin
Immortal
Immortal

Hi Mike,

If you use the SQL Server Management Studio UI:

- You would create the (SRM) db user by right-clicking the Users folder

under your database's Security folder. For example, if you use the

master database for SRM, you would navigate to

Databases->System Databases->master->Security->Users

- In the "general" page, you give the user a "Login name", and then

a "Default schema". Here is where you'd name the default schema

the same as the user/login name.

- No changes are needed (that I'm aware of) in the Securables and

Extended Properties pages.

If you use the SQLCMD.EXE command-line tool:

c:\> sqlcmd.exe -S should

all be the same name.

Hope this helps. If you need more clarification or have more questions,

please reply to this post.

Thanks,

Dave

0 Kudos

EXCELLENT!

That's for the blow by blow description. Reads like something from RTFM Guide...

I do find it kind weird that there has to be a match between username and schema name. These feel like oil and water values to be. I guess "that's just the way it is". Is that MS thing, or VMware thing???

Regards

Mike

Hi Mike,

If you use the SQL Server Management Studio UI:

- You would create the (SRM) db user by right-clicking the Users folder

under your database's Security folder. For example, if you use the

master database for SRM, you would navigate to

Databases->System Databases->master->Security->Users

- In the "general" page, you give the user a "Login name", and then

a "Default schema". Here is where you'd name the default schema

the same as the user/login name.

- No changes are needed (that I'm aware of) in the Securables and

Extended Properties pages.

If you use the SQLCMD.EXE command-line tool:

c:\> sqlcmd.exe -S <server_name\service_name> -H <IP_or_Hostname> -U sa

1> create login <login_name> with password='password'

2> create user <user_name> for login <login_name> with default_schema=<schema_name>

3> grant connect to <user_name>

4> go

1> create schema <schema_name> authorization <user_name>

2> grant create table to <user_name>

3> grant create type to <user_name>

4> go

In this scenario, <login_name>, <user_name>, and <schema_name> should

all be the same name.

Hope this helps. If you need more clarification or have more questions,

please reply to this post.

Thanks,

Dave

Hi Mike,

If you use the SQL Server Management Studio UI:

- You would create the (SRM) db user by right-clicking the Users folder

under your database's Security folder. For example, if you use the

master database for SRM, you would navigate to

Databases->System Databases->master->Security->Users

- In the "general" page, you give the user a "Login name", and then

a "Default schema". Here is where you'd name the default schema

the same as the user/login name.

- No changes are needed (that I'm aware of) in the Securables and

Extended Properties pages.

If you use the SQLCMD.EXE command-line tool:

c:\> sqlcmd.exe -S <server_name\service_name> -H <IP_or_Hostname> -U sa

1> create login <login_name> with password='password'

2> create user <user_name> for login <login_name> with default_schema=<schema_name>

3> grant connect to <user_name>

4> go

1> create schema <schema_name> authorization <user_name>

2> grant create table to <user_name>

3> grant create type to <user_name>

4> go

In this scenario, <login_name>, <user_name>, and <schema_name> should

all be the same name.

Hope this helps. If you need more clarification or have more questions,

please reply to this post.

Thanks,

Dave

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
admin
Immortal
Immortal

Hi Mike,

You are right - the settings (username and schema name) should

normally be unrelated. However,

a)To make installation more uniform (regardless of DB type), having

them be the same is easier to manage. As a related note, Oracle

gives you a default schema that matches the username when you

create an account, so we do the same for SQL Server.

b) When creating an account in SQL Server, it is quite likely that you'll

end up (inadvertently) using the default "dbo" schema, which causes

a lot of headaches (mainly due to permissions/roles as I believe this

schema is owned by a privileged user).

Hope this helps,

Dave

0 Kudos
gauche
Enthusiast
Enthusiast

About the repair array managers button use cases.

I was really happy when I saw this show up in a release after the initial beta. I'll not take credit but I know I was one of those who said it was needed.

Why?

In my case it was that I had configured the array managers in the inital setup rather lazily. I only entered one IP address of one controller with credentials. That works great so long as that particular controller is not offline at the time a test or failover occurs.

Then I went to do a failover after killing the production site, and out of pure bad luck, the controller I had put in the IP address of in the DR site was offline too. The SAN was there, and could do failover, but SRM was trying to talk to the wrong IP address. The repair managers button gives you a way to reconfigure your array information, like login and IP address, even when the primary site is already offline.

The same issue could happen if by bad luck someone changed the SANs admin password after the production site died.

I think these scenarios are unlikely but possible. It would suck if they totally disabled SRM.

I hope that helps.

Adam Carter Product Manager LeftHand Networks, an HP company
0 Kudos

Gauche,

What's your real name. I've taken your scenario, and fleshed it out. I would like to acknowledge your contribution in my book...

Regards

Mike

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos

Thanks for this additional info... To be honest I'm getting into a horrible muddle over this whole schema business. I guess what's being exposed her is my very crude understanding off SQL.

I had a look around at the locations for setting the schema to be the same as the username - a very confusing dialog box to the unitiatied like me. Plus I find all this schema business incrediably scary!

Plus there are no step by step instructions in the admin guide. I want to include such step by step instructions in my new book, but I'm considering dropping it all together - because I don't feel at all confident in this part.

The admin guide states bald facts like "You must have bulk insert administrator privileges.". But as VMware guy, I have no idea how to set these - or the consequences of getting this wrong...

Regards

Mike

Hi Mike,

You are right - the settings (username and schema name) should

normally be unrelated. However,

a)To make installation more uniform (regardless of DB type), having

them be the same is easier to manage. As a related note, Oracle

gives you a default schema that matches the username when you

create an account, so we do the same for SQL Server.

b) When creating an account in SQL Server, it is quite likely that you'll

end up (inadvertently) using the default "dbo" schema, which causes

a lot of headaches (mainly due to permissions/roles as I believe this

schema is owned by a privileged user).

Hope this helps,

Dave

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
admin
Immortal
Immortal

Hi Mike,

We decided not to include database administration specifics in the

Admin Guide because

a) It is best left to the Dabatase Administrator (DBA), since each

will have a particular way of administering accounts. (Similarly, we

don't discuss how to setup array replication.)

b) Each DB version (of Oracle, SQL Server, etc) that we support

is slightly different, and can be administered via a UI or command

line.

c) You can write an entire book on this subject alone. Smiley Wink

I believe that the "bulk insert privilege" is only needed when "bulk

inserting" into a table that's not owned by the user. This is probably

not needed if the user owns the tables.

Hope this helps,

Dave

0 Kudos

Hi Mike,

We decided not to include database administration specifics in the

Admin Guide because

a) It is best left to the Dabatase Administrator (DBA), since each

will have a particular way of administering accounts. (Similarly, we

don't discuss how to setup array replication.)

b) Each DB version (of Oracle, SQL Server, etc) that we support

is slightly different, and can be administered via a UI or command

line.

c) You can write an entire book on this subject alone. Smiley Wink

I believe that the "bulk insert privilege" is only needed when "bulk

inserting" into a table that's not owned by the user. This is probably

not needed if the user owns the tables.

Hope this helps,

Dave

I do take your point about the storage issues, but I'm not sure the same argument applies to the database.

Firstly, in other admin guides - notably the virtualcenter guide there very clear DB permissions outlined - and also a step by step for SQL and Oracle. I think we need to be realistic here - 99% of VMware customers will be setting up on SQL 2005. I was attending the SRM Beta Course this week in Frimley - and the slide there talked about setting DB_OWNER on the DB which isn't mentioned at all in the SRM Admin guide...

Secondly, there is an assumption that the customer is working in a super-large corportate where there is DBA team that this can be laid off on to... What if your VMware guy on your own (like I am) and your doing a proof-of-concept... some guidence might be helpful to these people...

Thirdly, I appreicate that SQL is a topic in its own right - but some step-by-step getting-started like information is all that's desired....

Finally, I guess we could sit and argue the tosh on this until the cows come home.... So I will drop it. BUT, out off interest how do you or the SRM Team in EMEA setup SQL2K5 with SRM. Would share your practises with the community?

Regards

Mike

Regards
Michelle Laverick
@m_laverick
http://www.michellelaverick.com
0 Kudos
admin
Immortal
Immortal

Hey, thanks for the pointer about dbowner. That fixed the problem I was running into. I'm setting up a POC, and we kept getting the "Failed to create database table" error during the install. We finally deleted the database and recreated it so that the user OWNED the database. Here is what we did (We are using MS SQL 2005)

  • Create a user (VMwareSRM) in the database (with SQL server authentication)

  • Create database (also named VMwareSRM) OWNED by user VMwareSRM

  • Create a DSN to point to the VMwareSRM database

There are probably good reasons to not be the database owner in production, but it seems to work for a POC.

0 Kudos
Itzikr
Enthusiast
Enthusiast

the other reason to "repair arrays" is to change from one-way storage replicaiton to bi-replication with SRM support..

you need the "repair arrays" to do so.

Itzik

Itzik Reich
0 Kudos