I love the vCenter Server Appliance. The migration works pretty well. Still from time to time I stumble across minor problems (which until now were always quite easy to workaround/fix).
One of this migration ‘issues’ I was faced with recently at a customers site.
We migrated a vCenter against an ESXi host which was using a distributed switch and the corresponding portgroup as a target network.
Since we add the virtual network adapter directly on the ESXi host to the distributed switch we need to have an ephemeral portgroup (otherwise only the vCenter could add the VMs network adapter to this portgroup).
The general process of the migration look like the following.
- Deploy a new and empty vCenter Server appliance and connect it to the network
- A temporary IP-address is given to this vCenter Server appliance
- All relevant data of the source windows based vCenter Server is exported and transferrred over the network to the new vCenter Server appliance
- When the whole data-set is transferred, shutdown the original vCenter and give the new vCSA the network identity of the original vCenter
Unfortunately the last step was not working properly. After a certain amount of time (and coffee) the migration process has stuck at 50% – Shutting down source machine
Within the vSphere world we have currently one goal regarding our vCenter. Migrate it from a Windows based installation to the vCenter Server Appliance (vCSA).
The doing of this migration is pretty straight forward and works pretty well (e.g. here). But since we will shutdown the original vCenter VM based on Windows afterwards we need to make sure how to deal with applications that were running besides the vCenter.
We need to migrate them as well. Especially in case of the Horizon View Composer we need to do some proper planning, otherwise our linked-clones (which require the composer) cannot be created and maintained anymore (refresh, rebalance, recompose (R-R-R) operations).
Doing that migration is quite straight-forward. But we need to do some specific and not very well known tasks before we can do all of the steps.
Goal: Migrate the vCenter to the vCSA and get rid of all currently used Oracle Databases within the VMware vSphere & Horizon environment.
- Define a Maintenance windows and make sure no further Horizon View maintenance operations takes place (R-R-R).
- Backup the Horizon Composer Database with the included View backup mechanism.
- Create Windows Server for the Composer (compvm)
- Create a Database for the Composer and the corresponding ODBC connection.
- Restore the Backup on the compvm
- Repoint Horizon within the View Admin to the new Composer
- Test Maintenance Operations
- Clean up old databases.
A minor problem I was faced while upgrading my lab environment to vSphere 6.5 was that during the Migration wizard the following error occurred:
A problem occurred while connecting to the migration assistant on the VUM machine
Even though vSphere 6.5 has been announced and not released yet Since vSphere and vCenter 6.5 are released now, a customer engagement put me into a position to gather much more information about characteristics and limitations within vCenter 6.5.
In the following I will discuss some of the upcoming and current vCenter characteristics that might not be completely aware (are not well documented) within the field /community.
Thanks VMware @Twitter community for helping me out here. Once again I really benefit from this great network out there.
The goal was to define a logical and physical design for the new vCenter release. Within the project we will have two phases
- phase: vCenter 6.0
- phase: vCenter 6.5
We will give the GA release of vCenter 6.5 a minimum time of 3 months to observe its behaviour and production readiness. Since we might require feature from the vCenter 6.0 release we want to design that is ready for an easy transition from 5.5 over 6.0 to 6.5.
However if you ever decide to move on to vSphere or vCenter 6.5. Please check the upgrade sequence here first & check the compatibilities (within VMware’s and 3rd party products).
- Windows based vCenter (vCenter 5.5 U2e)
- SQL Server installed on the vCenter Windows
After fixing a failed SSD of one of my lab-hosts I had some minor issues with my vCenter. Whenever I logged on into it I received this error.
“ An error occured while sending an authentication request to the vCenter Single Sign-On server – An error occured when processing the metadate during vCenter Single Sign-On setup – null.”
fair enough I checked the :5480 VAMI of my PSC and vCenter and the vCenter showed me the SSO was not initialized.
### UPDATE: I received some posts / comments that my approaced way does NOT work when using LACP. I haven’t had the time to get deeper into that topic, but please be aware of that fact.
Reviewing Google analytics for my old blog on vxpertise.net showed that my article a few years ago is still kind of famous.
It explains how the distributed switch import/export feature can be used to migrate existing ESXi to a new vCenter. I extended the information explained in this blog post with a few lines of PowerCLI code that makes the whole process a lot of easier/faster/less error-prone.
This requirements is raising up more and more in environments of people I deal with. Especially the awesome vCenter Server Appliance (vCSA) convinces people to create a new vCenter from scratch.
Lets upgrade our vCenter
*** Updated (22-04-2016): Links changed for vCenter 6.0U2 release.
There are a lot of great blogs out there about the process of upgrading the vCenter from 5.X to the most current version 6.0U2.
Having done the upgrade now in multiple production environments I try to summarize the general process and potential caveats. The following article is more a general approach and not specifically tied to a certain version. I start with the key facts outcome first. The detailed description where those key facts are extracted from are mentioned afterwards.