Building a new vCenter onto a Distributed Switch July 10, 2012Posted by General Zod in Networking, Tech, VMware.
Normally, I would keep my vCenter on the default Simple vSwitch so that it rides on the same VLAN that the ESXi Hosts exist on. When you’re planning your environment, it’s always wise to keep the old KISS adage in mind:
Keep It Simple, Stupid!
Well… recently, I had a customer who had separated all of their ESXi Hosts to a dedicated VLAN, and had (due to some remote access rules that were put in place for another customer) placed their vCenter on a separate VLAN accessed via a PortGroup on a Distributed vSwitch which leveraged trunking ports. This provided a small challenge…
I’d been brought in because the customer’s new Administrator (whom we’ll call David) was also very green to VMware. The company wanted me to upgrade their vCenter and Hosts to vSphere 5. (Also, they were hoping that I would teach David how to manage their VMware environment without billing them for a ton of extra hours.)
Well… here’s the challenge. I wasn’t allowed to actually “upgrade” their vCenter (as it was being used as an authentication pass-through by their Citrix environment), unless I was willing to do it at 12-midnight. I’m not stranger to night work, but the company was a little tight-fisted and didn’t want to pay me for off-peak hours.
Anyway… I was told that I had to build a new vCenter. No worries. We had a couple of remote SQL databases created to leverage, and I sat back and instructed David on how to setup vCenter, Update Manager, etc.
We built the NEW “vCenter5svr” VM within the environment being managed by the OLD “vCenter4svr” VM (using an IP on the same VLAN as the Hosts). Then, we setup the Datacenter and Cluster, imported one of the empty Hosts (which we’ll call “HOST1”), and configured the new Distributed vSwitch with the multiple PortGroups for each needed VLAN. So now we need to put a new IP on the vCenter and relocate it to the alternate VLAN on the dvSwitch.
Here’s the Catch-22… we need to put the new vCenter5svr VM on the dvSwitch while the VM is OFF… but with the VM turned off, it’s not possible to access the dvSwitch to get it on the correct VLAN… and I’ll not even bother getting into the hassle of getting connectivity to the remote SQL databases.
Sure… you could temporarily run some additional cabling to get it on the correct VLAN and then change it up later… but that thought makes me tired. (Work smarter! Not harder!) So what to do?
Well… the answer is simple. And I’m certain that there are other ways to do this, but the following is my simple and effective solution.
- Login to your vSphere client against vCenter4svr.
- Power OFF the vCenter5svr VM, and CLONE it to another new VM… let’s call it “vCenter5svr_B”.
- Once the clone is completed, power ON the vCenter5svr_B VM.
- Console into vCenter5svr_B, and STOP the vCenter services. Configure the OS with an appropriate IP for the destination VLAN.
- Shutdown vCenter5svr_B again.
- Power ON the original vCenter5svr.
- REMOVE the vCenter5svr_B VM from inventory.
- Login to your vSphere client against vCenter5svr.
- ADD the vCenter5svr_B VM to the inventory.
- Place the vCenter5svr_B VM into the appropriate PortGroup on the dvSwitch. (Remember that these changes are being stored in the remote database; NOT on the server.)
- Close your Client that’s connected to vCenter5svr.
- Return to your Client that is connected to vCenter4svr, perform a clean shutdown of the vCenter5svr VM. (Both vCenter5svr and vCenter5svr_B should now be powered OFF.)
- Login to your vSphere client against HOST1 using the ROOT credentials.
- Power ON the vCenter5svr_B VM. If you did everything correctly, then it will become ping-able (Is that a word?) in a few minutes.
How? Well, we’d previously placed vCenter5svr_B on the dvSwitch… so HOST1 already knows that the VM needs to communicate across the dvSwitch. So it will come online, connect to the database… and get right back to work as the new vCenter5svr.
- Login to your vSphere Client against vCenter5svr (which is actually running in vCenter5svr_B)… and confirm that all is functioning well.
- Rename the vCenter5svr_B VM to “vCenter5svr” ( …just so there’s no confusion in the future).
- Return to your vCenter4svr Client, and DELETE the original vCenter5svr VM.
- Congratulate yourself… and express to your Manager how you’ve successfully handled this problem without having to waste company dollars on external vendor assistance.
Well… to finish my story, I demonstrated to David how he could save a lot of time by migrating the Hosts and the 80-some VMs himself during the evening hours. David was nervous about doing it himself, so I demonstrated the process for him… and gave him my mobile number in case of an emergency.
- Schedule a night-time maintenance outage for all of your VMs.
- Make note of hostnames for each Host managed by the vCenter4svr.
- Make use of the VM “Annotations” to make a note indicating which VLAN each individual VM belongs on. (You won’t be able to tell after the import to the vCenter5svr… so make your notes now.)
- At the time of your evening maintenance window, power OFF all of the VMs managed by the vCenter4svr. MAKE SURE that the vCenter4svr VM is the LAST VM to be powered off.
- Login to your vSphere Client against vCenter5svr.
- Add each Host to the vCenter server. You’ll be warned that each Host is already being managed by another vCenter. Proceed with each import, and accept any licensing imports that you may be prompted with.
- On each VM, edit the Settings and place the vNIC onto the appropriate PortGroup. Then, power them the VM on.
David did call me up that night, but only for a quick question that didn’t take longer than 3 minutes… so didn’t bother with billing him for it. (A friendly favor from time-to-time will usually bring more work in the future.)
What was his question? Their Citrix XenDesktop environment was leveraging vCenter4svr as an authentication pass-through for a small group of VDI workstations. (Remember I mentioned this earlier? This was the first I’d been informed of this particular point.) David wanted to know if moving the VMs to vCenter5svr would impact that functionality.
The answer is… NO, provided you turn vCenter4svr back ON. The Citrix XenDesktop environment wouldn’t care where the VMs were housed… provided its vCenter was still online to provide authentication pass-through.
So he turned vCenter4svr back on that evening, and successfully tested to confirm that the functionality had not been impacted. In the morning, we met with their resident Citrix expert and advised him to redirect the authentication to the new vCenter5svr. (I’m not entirely certain how complicated that turned out to be, but I never heard a single complaint about it.)
In the end, David did manage to get all of his ESXi 4 Hosts successfully imported into his vCenter 5 server. Then, I showed up the following day for 2 hours… just long enough to demonstrate to David such things as vMotion, educate him a little on HA and the use of Maintenance Mode, and how to rebuild a Host to the ESXi 5 hypervisor.
With David properly empowered… he handled the rest of the migrations on his own. I recommended to him a book on VMware management… and departed for my next customer.
I’ve since gotten more work from David… and he’s always happy to see me. Some customers tend to get grouchy about having to get you to come out… thinking that you’re only there to bleed them dry. David welcomes my visits because he knows that I’m not trying to hike up the bill… and he’s almost guaranteed to learn something new.