August 30, 2017 at 9:00 am
Hi All,
we have a requirement to move one of our VM ( SQL Server) connected to a data store to a new SAN. How I have been involved moving SQL Server databases to new SAN in the past ,however, this time they will be moving the C and D drives where the SQL Server was installed too. This creates a confusion for me as how to go about it. I am looking for the steps or main points to implement to accomplish this.
So Far I have come up with this.
let the storage people present the New drives with the same size for data file, log files, tempDB files.
Any help is appreciated.
B
August 30, 2017 at 9:11 am
the esx admins should be covering the move of the virtual disks between datastores
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 30, 2017 at 9:36 am
Correct- U r right.
Additionally - once they copy the data from the old data-store to the new SAN. lets say for example we have some thing like below.
VM
From
SQL installed - drive : C
Data File : D
Log file : L
Temp drive: T
Backup drive : Z
To
SQL installed - Drive : E
Data File : K
Log File : M
Temp db : P
Backup : X
This is what I am thinking about sugesting.
copy the drive to the new SAN with different letters ( see above)
Take SQL Server services offline.
Rename the current drive letter in the old data-store to some thing different.
rename the new SAN drive letters to the old ones.
Restart the SQL server and it should be up and running.
U guys think I am on the right track or totally wrong here.
regards,
Bobby
August 30, 2017 at 11:37 am
I think what Perry is suggesting (correct me if I am wrong though) is that your SAN team would handle everything with this.
They would migrate the data from the old system to the new and your VM would be presented with the same virtual disk data it had before but different physical disks as it would be on the new SAN. The VM would get the same drive letters and there would be no data migration or configuration changes required by you.
The VM shouldn't even notice anything changed unless your SAN team adds more disk space for you.
I would discuss with your SAN team to figure out if they want you to migrate the data or if that is something they are doing. I believe they should be able to do it faster from the back end than from the VM side. You would have some downtime while the data was transferred, but you'd have the same problem with the method you described. Plus the method you described introduces a problem when you try to move the C: drive as that is likely where Windows sits and it won't let you unmount that drive while windows is running.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
August 30, 2017 at 12:00 pm
BMG and Perry are correct, you shouldn't, in theory, need to do anything other than make sure SQL starts up after the SAN / VMware team handle the move of the disks.
All my servers are hosted on VMware, and the VMware team has had to move their storage a couple times to new datastores. All I've ever needed to do in those situations was sit back, wait for them to call me and tell me the move was done (it would require a shutdown of the VM,) then connect and ensure SQL started up all its services and all the databases had come online (which they always have so far, as it's just a normal OS shutdown.)
August 30, 2017 at 12:36 pm
Thanks Guys, it was really helpfull. Thanks for BMG002 to point out correctly that since C drive is in question and it has windows installed on it, the VM have to be shutdown first.
Many Thanks for the insight.
B
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply