Category: Uncategorized

As I was getting started in virtualization, I noticed a heavy reoccurrence of a few people sharing information, fixes and know-how on topics that I was searching. People like @anthonyspiteri, @DuncanYB, @lamw, @FrankDenneman to name a few, providing technical deep-dives about the things I was trying to deploy.

I was handed the resources to build an infrastructure and tasks with deploying them in sites across the globe. Pretty heavy for a new guy. These blogs really helped me get to terms with what I needed to understand, what the architecture would look like and how I should go about it.One of the topics that took a bit to understand was Virtual Distributed Switches.Documentation on it for a newcomer was too dense, some blogs matched the language and it made it hard to grasp the idea of it during the day that I spent concentrating on it. I continued looking at diagrams and reading VMware’s own documentation but it was taking too long to click.

I did finally get it after about half an hour or so and why it would meant so much for deploying this infrastructure. But there was always that voice in the back of my head telling me that it could have been easier. It SHOULD be easier. I know that a lot of people just getting into this are not going to have that same opportunity as I had, but they could atlas benefit from someone breaking it down. I won’t call this Virtualization for Dummies, but I do want to help newcomers.

So I’m starting this blog to break down the concepts, functions and roles of different virtualization topics to help those trying to get a basic idea on them, so that when they get to VMware’s documentation, its already deciphered for them. I hope this helps a few people get started and I hope it proves meaningful. So join me for now as I write the “New2” series. I ‘ll write a couple others from the perspective of being a Service Provider (Licensing), Deep-Dive (when I can) and just general topics.

I may be relatively new to the virtualization game but I am honored to be sent to VMworld on behalf of my company. As my first time at VMworld, it’s going to be interesting, exhausting and from what I can tell, hard to keep up. I’ll be doing my best but I thought I could write my opinions about the products I see, sessions I’ve joined and experiences here. Due to my companies different approach to deployments and how we handle data, I think it will skew my judgement of products a bit. I’ll explain more later but it’s interesting how things like Disaster Recovery platforms don’t fall into a particularly useful part of my companies architecture and needs. It makes for fun conversation with vendors at least, when they realize that they products don’t actually suite all customers. To say the least, working in telecommunications, even in a small part makes architecture for virtualization quite a bit different.

I’ll be looking forward to partner exchange and a could telecom based sessions at VMworld as well as sessions on performance tuning and automation.

I’ve written a couple things from time to time on my tumblr page. It’s not really where I wanted my infrequent blog to stay, and I already have a web hosting account, so here I am.

I think I want to make this into some sort of research journal or log about my journey through data center virtualization. I’ve got a long ways to go and much to learn but I really need to find the time to write.

I think the next post might cover how I got to where I am now, but I feel like I would have to be necessarily vague on points for the sake of my employment… Need to work on that.

I hope to turn this into something later on, but for now it’s an experiment. Really what I would love to do is bring more people into data center virtualization. Younger people like college students. This has been a tremendous career booster for me and I feel obligated to help others do the same. But that’s a blog post for another day.

So here is to starting this. I hope someone reads this and finds it useful (talking about future posts of course).

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.