After converting to VMWare MS SQL won't start

[jonaszal]

Hello,

maybe someone can help me.

After full backup of Windows 2008 R2 server (with MS SQL) we duplicated (I mean P2V convert) it to VMWare.

But then we started converted server the MSSQL instances didn't start (we have two). In log file I have found that there was problems with permissions.

2014-04-25 08:36:54.17 spid7s      Starting up database 'master'.
2014-04-25 08:36:54.18 spid7s      Error: 17204, Severity: 16, State: 1.
2014-04-25 08:36:54.18 spid7s      FCB::Open failed: Could not open file C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLLAIKINAS\MSSQL\DATA\master.mdf for file number 1.  OS error: 5(failed to retrieve text for this error. Reason: 15100).
2014-04-25 08:36:54.18 spid7s      Error: 5120, Severity: 16, State: 101.
2014-04-25 08:36:54.18 spid7s      Unable to open the physical file "C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLLAIKINAS\MSSQL\DATA\master.mdf". Operating system error 5: "5(failed to retrieve text for this error. Reason: 15105)".
2014-04-25 08:36:54.18 spid7s      Error: 17204, Severity: 16, State: 1.
2014-04-25 08:36:54.18 spid7s      FCB::Open failed: Could not open file C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLLAIKINAS\MSSQL\DATA\mastlog.ldf for file number 2.  OS error: 5(failed to retrieve text for this error. Reason: 15105).
2014-04-25 08:36:54.18 spid7s      Error: 5120, Severity: 16, State: 101.
2014-04-25 08:36:54.18 spid7s      Unable to open the physical file "C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLLAIKINAS\MSSQL\DATA\mastlog.ldf". Operating system error 5: "5(failed to retrieve text for this error. Reason: 15105)".
 

Same error on both instances.

It looks like after convert all files in DATA directory looses its initial permissions. DATA directory has Full control permission for SQLServerMSSQLUser$... group but all files in it don't.

Maybe someone has solution.

Here is info about servers:

For backup we use Sym BE 2012 SP4

SQL Server: Windows 2008 R2, MS SQL 2008 R2 Standart joined to AD

Thanks in advance.

[pkh]

The P2V conversion is only the first stage.  You have to restore the SQL databases before you can start up SQL.

[Colin_Weaver]

There is apparently a way to recover SQL directly during a P2V however you have to edit some options in the P2V job as I believe the default is to convert only the drives and not the databases. Someware in the options of the convert job is a location to choose what resources you are converting and I think you can select SQL in there and we then inject the SQL database into the VMDK/VHD

Chances are you did not realize that for database technologies you can't just use the P2V defaults.

EDIT: Some further notes / thoughts

1) This ability to do a single-pass convert of database technology does not mean SDR can now do single-pass restores, SDR still has that limitation as the WinPE environment does not have the correct library files to achieve a similar result.

2) For some reason this single-pass convert ability has not been well publicised (even within Symantec) even to the extent where some of my own earlier posts in this forum covering the same subject may still state that we can't do the single pass convert (please ignore these earlier posts)

[jonaszal]

I have tried that. The problem is that if MS SQL service is not running (which in my case is not) I cannot restore SQL databases. I get error from SBE.

[jonaszal]

I convert my server from Full backup which includes Disks, System State and SQL instances (Disaster recovery light is ON).

Converting is done right after Full backup job.

If I change SQL databases files permissions (add SQLUser group with Full access) I can start up SQL.

[Colin_Weaver]

Ok that means the convert worked and you have some kind of restricted permissions

Do you know what these permsisison were on the physcial server prior to the backup?

Also are you testing this convert with a domain security structure as you can end up with security blocks because two computers with the same names and security SIDs cannot access the same domain at the same time. So it may just be that you can't correctly authenticate against your domain controller and changing some local security controls then bypasses this problem.

[jonaszal]

On the original server every database file (*.mdf, *.mdl) has the same permission settings as DATA catalog. I mean every file has permissions settings for SQLServerMSSQLUser$_ServerName_$_InstanceName_ group (it was created by SQL install)

On the converted server DATA catalog has those permissions but files in it don't.

I shutdown original server prior testing converted server to avoid conflicts.