Moving large VMDK’s from one Windows File Server to another in vSphere 4.X while maintaining share information

Moving large VMDK’s from one Windows File Server to another in vSphere 4.X

At my Job we are nearing the end of our W2k8R2 upgrades. The only W2k3 servers left are our file servers. In planning to upgrade these W2k3 file servers we decided to create the new W2k8R2 file servers in advanced and during scheduled down time migrate the VMDK’s holding the shares to the new VM.  An overview of the plan was as follows:

1. Create a new W2K8R2 VM, called NewFileServer
2. On FileServer (W2k3) remove the virtual hard drive holding the share info
3. Move the VMDK to the datastore folder of NewFileServer and attach it to NewFileServer
4. Verify data is ok, if so rename FileServer  to OldFileServer and rename NewFileServer to FileServer
5. Recreate shares and verify access works on FileServer (W2K8R2), if so remove OldFileServer

Below are the actual steps

1. Ensure a recent backup of the W2k3 source VM has been made
2. Remove all snapshots from the W2k3 source VM
3. Export Share information from the Registry of the W2K3 source VM

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

1. This contains names and security for all types of shares (printers, files, etc)
4. Under Windows uninstall the hard drive containing the share data and power down the W2K3 source VM
5. In the vSphere client remove the virtual hard drive from the W2K3 source VM
6. While still in the vSphere client go to the Datastores and move the VMDK to the proper datastore folder where the W2k8R2 target VM is located
7. In the vSphere client add the new disk to the W2k8R2 target VM
8. Go to Disk management and bring the disk online
1. It may show up as a foreign disk that needs to be imported
9. Verify file data is intact
10. Rename or dis-join the old VM from the domain and change IP from static to DHCP
1. The AD account should remove itself if renamed.
2. If disjoined the AD account will rename but the AD account cannot be reset,  it will need to be deleted and a new one will need to be created
11. On the new VM rename it’s Window’s computer name to match the old VM, and change IP to static and then restart
12. Once rebooted Import the exported registry file and restart
13. Or just restart the Windows Server Service
14. Verify that the shares work

House Keeping

This doesn’t need to be done but it helps make sure the VM files and Datastore folders match the VM’s AD name

1. Shutdown and remove both VM’s from the inventory of vCenter (DO NOT DELETE THE VM’s)
2. Browse to the datastore and create a new folder for the old VM
3. Move all the files of the old VM to the new folder
4. Move all the files of the new VM to the old VMs folder, delete the now empty new VM folder
5. Login to the to a host that has access to the Datastore
1. Login into the ESXi host via SSH
1. If SSH is not on then login into ESXi console of the host you’re working with
2. Turn on SSH access
1. Set the SSH timeout for 30 or 60 minutes so you don’t have to remember to turn it off
2. Browse to the data store, eg.

1. cd "/vmfs/volumes/NX4-SATA-RAID5-01/Intranet/"

1. The CLI is case sensitive
3. Find the VMDK in question and rename it by

1. vmkfstools -E mail2_2.vmdk intranet_2.vmdk

2. The Flat file will get renamed once the vmdk is renamed
4. Verify the file was renamed by running ls- l
5. The various other files can also be renamed in in the CLI as well, e.g.

1. mv vm-old.vmx vm-new.vmx

2. This needs to be done for  the following file types
1. NVRAM
2. VMSD
3. VMX
4. VMXF
3. Description of those files if you are curious
6. Stay logged in on the off-chance you need to reenter the SSH, otherwise logout
6. Once finished browse to the datastore and rename any non VMDK file that still has the old name
7. Re-Add both VMs to the inventory
8. For both VMS, In the VM settings remove the entry for the OLD VMDK and add the renamed VMDK (make sure it’s SCSI (0:0) Hard disk 1)
9. Turn both on VMs, when prompted select “I moved it”
10. Verify both still function.
11. Check any auxiliary info (Repoint Backup Agents etc.)
12. Log out of the SSH session if you already haven’t