I should be posting more often, so here is a first attempt.
Needed to consider moving to the vCSA, both because I am killing the SQL Express database, and also because it would make moving to vSphere 6 easier. In an effort to do so, I happened to hear about a fling (funny, the names given things by engineers), that was developed by VMware engineers during the Orlando VMUG event. I read through the entire comments page, making sure there was nothing seriously wrong with it’s current iteration. First thing that stood out was that it was made for Windows vCenter deployments that use an external database. Carp. Don’t have that. After discussing all of this and working on this with Shannon Fitzpatrick (@shanfitz), we decided to move forward. We built a test environment to work on this, so as not to disturb our production deployments.
William Lam (@lamw) pointed out further in the comments that he had success doing a procedure to side step that, that allowed him to migrate a SQL Express database. Essentially, the fling requires you to power down the original vCenter Deployment, then power on the vCSA. The vCSA should be deployed with the same IP and Hostname as the original, and you just need to do some configuration work to get it going.
I thought, great! I’ll just Re-IP when it asks me to power it down, point the fling at the new IP when it wants to copy the SQL DB and viola! Except it wasn’t that easy. Of course it wasn’t.
First and foremost, make sure that when you deploy the appliance, to use the web interface. It naturally has the ability to put the IP and Hostname into the pre-configuration portion of the VM deployment. This didn’t happen with the fat client on windows, so I found myself trying to edit the SUSE Linux files to deploy the IP and Hostname that I wanted. Not as fun, but not hard for me either.
Second, after deploying the vCSA via the web client, I would disconnect the NIC. This made it so that there was no IP conflicts happening on the network and I didn’t have to wait for it to boot, yes I am too lazy to wait 10-17 seconds. Shannon made this recommendation and it was perfect.
So here we go, started the migration, copying the data from the Windows Server version of vCenter, and it took all but the DB, which was expected. I re-IP’d the vCenter server, shutdown the VirtualCenter Server service and attempted to continued to the DB portion of the fling. This is where the fun happened. As I sat there trying to figure out the “sa” DB User password, I couldn’t get it to work. It was a complete pain in the rear on this, and no matter what I tried, no go.
Ok, well after a couple tries, the fling even gives up and moves on, it just gives you the option to continue the migration, starting with connecting to the vCSA all over again, or starting from the beginning. Apparently even the fling thought it best to start back from one. Reset, and start again. So I left the vCSA running and disconnected the NIC. Re-IP’d the original back into place and tried again. No go, apparently when you start the fling it also stops the vpxd service on the vCSA, so when you are back to the “Power up the appliance” stage, you should start the vCenter service from the management web console. Little tip I learned.
After awhile, it was just easier to spin up a copy of SQL temporarily and backup the DB and and restore it externally. But learned something there as well. Now I’m no DBA, but apparently when you set the backup location, and you decide to also add a location that is easier for you to find, it puts files in both locations. So when I transferred the backup, or what I thought was the backup, from the easier location, I really only had 1 out of 2 of the “family” of files. After googling, since I’m no DBA, i noticed I needed both. So now, naturally my personal notes day in almost bold lettering “DO NOT TOUCH the backup location”.
Since I got to set the “sa” users password myself in the temp deployment of SQL Server, it was smooth sailing from there. The DB copied over just fine, no hiccups or issues. And to top it all off, the access rights were already there, the inventory was ready to go, and not a single host was having issues.
Overall, this fling is gold. If you need to migrate, this is the way to do it. I only hope that VMware goes on to support this fully and supports it as a production ready tool. Kind of excited to test out more flings, and maybe suggest a few of my own. Overall, it’s very impressive and I look forward to watching it grow potentially into a product or tool offering.