relocate a VM hosting vCenter's SQL database

[vreiner]

I have vCenter running on a dedicated server but the vCenter SQL database is hosted on a VM (running SQL Server 2005). I need to move the SQL Server VM to a different storage system which I would normally do by shutting down the VM and doing a cold vMotion - but there is a Catch-22. I need vCenter to do the vMotion/file relocation, but I need to shut down the VM to in order to relocate it's files, which kills vCenter and therefore no vMotion.

Is there a clean or proper way to do this? Thanks!

[java_cat33]

You could storage vmotion your SQL VM to the new lun (assuming you are using ESX 3.5.x and VC 2.5.x).

[vreiner]

Unfortunately I'm using ESX 3.02

Victor Reiner

On Dec 19, 2008, at 6:34 PM, "java_cat33" <communities-emailer@vmware.com

[twoodland]

This might not be the best way, but this is what I would probably do.

Connect the VI client directly to the ESX server, and shut down that SQL vm. Browse the datastore, and download a copy of it to your local computer. Then, disconnect the VI client from the host it's on now, and connect it to the new host. Browse that datastore and upload it. You will have to manually reattach it at that point, but I'm pretty sure that would work.

[vreiner]

Well it's on a SAN so I can do a volume to volume copy of the whole VM

directory at the ESX console. Can I shut down the VM, disconnect the

VM from VirtualCenter, move the directory then reconnect it in

VirtualCenter?

Victor Reiner

On Dec 19, 2008, at 9:33 PM, "twoodland" <communities-

[java_cat33]

If you take a note of what ESX box it's running on, shutdown the SQL server VM and then copy the VM to the new datastore. You should be able to connect to the ESX server directly and remove the old instance of the VM from inventory.

You will then need to edit the settings of the copied VM to reflect it's new datstore path etc. After the modifications have been made you will be able to register the VM via the VI Client. Power it on.

Once VC is running again you might have to remove the old instance of the SQL server VM again from inventory while connected to the VC (as I think it will still be in the VC database) - and after successful testing - delete the old copy of the VM.

No other changes should be required as the only change being made is the lun the VM resides on.

[vreiner]

Editing the VM config is a scary process, I'm not sure what needs to

be changed. I tried that once before and the VM was broken for some

time till I stumbled through finding all the hard references. If

there is a guide of some sort pointing out where all the changes need

to be made I would feel better about it. I was hoping there was a

cleaner/more automated/ less risky way to do this.

Victor Reiner

On Dec 20, 2008, at 2:11 AM, "java_cat33" <communities-emailer@vmware.com

[java_cat33]

Firstly - Make sure there are no snapshots on the SQL box before copying the VM.

In regards to editing the settings files for the VM.....

Assuming the box has only 1 vmdk stored in the same folder as all the VM setting files and no snapshots...

You will have to edit the &lt;virtual machine&gt;.vmx file

Near the bottom of the file will be a setting named sched.swap.derivedName - Edit the path this looks at (will need to replace the long set of numbers - UUID that references the friendly name of your VMFS volume).

If you have multiple vmdks stored on different vmfs volumes - you will also need to edit the vmdk locations (within the vmx file) and will also need to edit the &lt;virtual machine&gt;.vmsd file.

Alternatively - Another method you could use to move your VM would be using an imaging tool. Do you have a tool such as Storagecraft Shadow Protect or Norton Ghost? You could boot the SQL VM off a boot CD and image it to the network somewhere. From here - Connect directly to an ESX box - create a new blank VM with the same settings and boot the new VM of the Ghost/Shadow Protect CD and restore the SQL VM image.