VMware’s KB 2113917 for repointing vCenter to a new PSC within the same site on vSphere 6 is straightforward. Only requires one command to run on the vCenter Server. However, the repoint will not work if the proxy setting is enabled on the vCenter Server. This is a bug and hopefully will be fixed in a future patch.
Below is the error message after running the repoint command with the proxy enabled.
Please check the configuration and retry
Using curl to test the port connectivity was fine for port 443 on the PSC. I could even access the page that is in the error message. tcpdump between the vCenter Server and PSC showed information on the proxy. That is odd since the repoint shouldn’t need a proxy. The proxy is there so the vCenter Server can get out for updates.
The proxy can be disabled on the vCenter Server’s Appliance Management UI; https://:5480 Then go to Networking…Proxy Settings…Edit and uncheck ‘Use a proxy server’. Restart the vCenter Server and run the repoint command again.
I am in the process of upgrading three vCenter Servers on 5.5 to 6. SSO was embedded on all three and SSO has been recently externalized to Windows Servers. The next step is to use the vCenter Server Migration Tool to migrate each SSO 5.5 server to PSC 6 appliance.
I went through the migration wizard and the migration was on its way. The PSC was deployed and the progress bar on the migration was moving along. However, when I opened the console for the PSC, there was an error; Upgrade EXPORT failed. Then the migration never finished.
I ran the migration again with VMware support since they did not know what could be causing the issue. I opened up the console for the PSC as soon as it was deployed and there was a quick message to look at UpgradeRunner.log. However, there was nothing useful in that log. Then checked out upgrade-export.log.
There were network related errors in upgrade-export.log. I knew I inputted everything correctly into the migration wizard and there was nothing that would block communication between anything involved. The IPv6 address in the log stuck out to me. The SSO Windows Server had a IPv6 address, but the wizard never asked for anything IPv6 related. I disabled IPv6 on the SSO server, ran the migration again, and everything went well.
Here’s one way to view the PSC’s logs. At the PSC’s console, hit Alt+F1. Then type the commands below.
shell.set –enabled True
Moral of the story is to disable IPv6 on all VMware related servers before using the vCenter Server Migration Tool. Then enable it after everything is on 6. This is just to be safe in case any other of the upgrades or migrations have similar issues. VMware support said they will have a knowledge base article on this issue. When they do, I will edit this article with a link so everyone can check out the latest directly from VMware.
I’m still amazed Veeam and it’s partners squeezed in 85 break out sessions throughout the event. I had a tough decision most of the time on which session to attend as many sessions shared the same time slot. Fortunately, the schedule listed details for each session saying if it was business, partner, or technical. Then technical had a few levels so that helped to describe how deep the session will go.
My favorite session was How to Back Up and Restore VMware vCenter Server Appliance (vCSA) and Platform Controllers Properly. The session was hosted by a Emad Younis, Technical Marketing Engineer from VMware, and Mike White, Technical Evangelist from Veeam Software. They started off talking about VMware Platform Services Controller. The PSC was new to vSphere 6 so it’s been around for a little while now, but good to get a refresher. Then they went into backing up and restoring the vCSA and PSC. Backing up the vCSA in 6 is the same as previous versions. Do not bother backing up the vCSA’s databases. Use Veeam or another product to back up the vCSA and PSC VMs. Then restore the vCSA VM directly to a host. However, the PSC is a little different if using Enhanced Linked Mode, which means there will be more than one PSC. Deploy a new PSC and join to the existing SSO domain. Replication will simply kick in and bring the PSC up to speed. If only one PSC, then just restore it.
I thought there would have been more love for Veeam ONE. There were actually only two sessions! I know it’s the sidekick to Back and Replication, but more sessions on it would have been appreciated. I attended one of the two. The second one wasn’t relevant to me since it was about how to scale Veeam ONE. My Veeam ONE server is fine. The session I attended, Take Out the Guesswork with Veeam ONE & Chargeback, went into some reports and alarms. A couple of the reports, powered off VMs and VMS with no archive copy are ones that I never looked. There are a great many of reports so nice to get some tips on others to look at outside of my routine ones. They talked about a useful tip on creating an alarm for a VM that has not be backed up for defined amount of time. This is good to catch a bug that sometime stops backing up VMs within a vApp with no warning or error.
The photo above was from What’s New in v10: A Deeper Dive, hosted by Anton Gostev. His sessions seemed to be the most popular by far. People were lining up for his sessions that were in the smaller rooms, but at least the deep dive was in the big hall.
The breakout sessions were hit and miss as some of the presenters did a better job than others with going through their topics. However, I certainly understand that every presenter puts in a lot of time and effort. I got something out of each session I went to. Perhaps one day I can think of an interesting topic to present and start small at a local VMUG.