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
- Simplified management of a multi location environment (suitable feature: vCenter 6.0 enhanced Linked mode)
- CA signed SSL everywhere (suitable feature: vCenter 6.0 PSC Sub-CA)
- Central VM Template Management (suitable feature: vCenter 6.0 Content-Library)
- Highly available vCenter (suitable feature: vCenter 6.5 vCenter HA-Mode)
- Quick recoverable vCenter (suitable feature: vCenter 6.5 integrated backup)
Out of the requirements and constraint (not direct 6.5 migration) the following design decisions might play an important role to define a suitable management solution.
- Migrate to vCenter Server Appliance (vCSA) or remain with Windows based vCenter
- Embedded Plattform Service Controller (PSC) or Distributed PSC
- PSC as Sub-CA that is capable of creating enterprise signed SSL Certificates for VMware components
In the real scenario much more design decisions are playing an important role (for blog post scope limitations I just mentioned a few). Let’s clarify some of the component characteristics to make sure we know about the basic functionality and limitations for the present or during a future transition to a next version (e.g. 6.0 -> 6.5).
Only if you know limitations and exact functionality of features you will be able to create the best solution to meet a customers requirements.
Once we have an overview about those limitations, functionalities and the transition costs to get from a) Version 6.0 to b) Version 6.5 we can plan accordingly and effectively.
vCenter Server Virtual Appliance aka vCSA is the future.
There is no bigger discussion necessary here, since VMware is actively recommending people to use the vCSA if there are no really suiteable reasons to do otherwise. Even though there will still be a Windows based version in 6.5 the day will come where the appliance is the only delivery option for VMware’s management component.
New features (like integrated backup or integrated High-Availability Options) are only available for the linux based (vCenter 6.0 -> SLES, vCenter 6.5 -> Photon OS) appliance.
With the release of the vCenter Server Appliance Migration Tool we can now migrate from vCenter 5.5 Windows to vCSA 6.0 in a supported way. Check out the FAQ and make sure to control the supported releases before migrating (Migration from windows 6.0 to vCSA 6.0 won’t work).
With the release of 6.5 we will gain more flexibility from which version we will be able to migrate from.
Make also sure to do upfront vCenter compatibility checks. I recommend to go through my vCenter upgrade article which is still valid nowadays.
The migration includes everything (distributed, switch, ids, hostname, certificates, etc.). No other system will recognize a difference after the migration took place.
From a fallback point of view vCSA upgrade and Windows to Linux migration are pretty useful since always new virtual machines gets deployed, connected to a temporary network and a data transfer takes place. Therefore the original instance remains quiet intact (don’t forget clean-up tasks after a successful migration).
Within vCenter 6.0 you will still need a Windows machine acting as the platform for the update manager. A vCSA integrated update manager will only be part of the version 6.5.
Configuring the PSC as a Subordinate Enterprise Certificate Authority
The biggest challenge when dealing with Certificates in vCenter 6.0 (or newer) is to remain comply with the corporates security policies. Since 6.0 the PSC can be configured as Intermediate CA which is now able to sign enterprise SSL certificates for the vCenter (and it’s solutions) and the ESXi hosts.
The process is quiet straight forward nowadays and pretty well documented by the VMware community, e.g. here.
Until now I don’t know about any improvements here in vCenter 6.5. I know from the field that for many security departments the feature-set of the PSC sub-ca was not ready for THEIR usage.
What happens if you repoint from e.g. an embedded PSC to an distributed PSC (or create multiple PSC)?
Thx Kyle Jenner for the hint. Read details on that topic here in his post.
How to increase vCenter’s availability and recoverability
The vCenter becomes more and more important in our infrastructure. Virtual Desktop Infrastructures, Automation of workflows and Cloud Services are highly dependant of a running vCenter service. Even though we can protect the vCenter with vSphere HA, we are only covering failure on ESXi Level (hypervisor or hardware). Applications / OS / Filesystem problems can be mitigated only in a limited way.
With vCenter 6.5 two features were introduced to increase the availability and recoverability.
With vCenter 6.5 (vCSA only) we can have a 3 node active-standby-witness construct that protects against OS/Application failures. The HA vCenter will protect all services on this VM (vCenter, WebClients, PSC, Autodeploy, etc.).
The usage of the new Photon OS as the underlying Linux Operating System the boot-time and therefore service recovery time will be reduced a lot. Check out Féidhlim O’Leary brilliant blog post on that topic.
In vCenter 6.0 or earlier the only way to achieve a full consistent backup of the vCenter was to backup the postgresql database with VMware provided scripts on the vCSA shell.
Besides that a crash-consistent backup could be created via the usage of the vSphere API for data protection (Veeam, etc.). Just make sure here that your backup solution allows recovery directly to an ESXi host. There are still candidates out there that only allows the recovery against another vCenter (chicken-egg-problematic).
With vCenter 6.5 we will be able to also dump all vCenter relevant information (vCenter, PSC) to a central file share and recover our vCenter out of this data.
To Enhanced Linked Mode, or not to enhanced linked mode… that is the question.
The good old discussion and most-often the reason if we want to do have a distributed Platform Service Controller setup (2VMs) or an embedded PSC (vCenter and PSC installed on the same operating system).
The biggest limitation here: No enhanced linked mode with an embedded PSC
Other important characteristics:
- Migration from embedded to distributed possible via cmsso-util repoint.
- Migration from distributed to embedded NOT possible.
- vCenter 6.5 high-availability mode not applicable for an external PSC. If you want a high-available vCenter in 6.5 and and a high-available PSC you can use the integrated feature for the vCenter,but still need a load-balancer and multiple PSCs to have an automatic failover in-case of a PSC failure).
- CMSSO-Util repoint within 6.5 is only possible if you remain in the same PSC site.
Enhanced Linked Mode and therefore external PSC increase the complexity of the management environment. So in case you don’t really rely on the enhanced linked mode feature, a simple embedded installation might be suitable (for simplicity reasons). Maybe the limitation of embedded PSC might go away in the future (or we can use the new HA-mode also for an external PSC).
I hope those information help you to find the best decisions within your system design. If you have any further comments or think something is missing. Let me know!
Thanks for twitter support and import: Fred Hofer aka vBrain, William Lam, Adam Eckerle, Emad Younis, Kyle Jenner, Myles Grey (and many more).
10 thoughts on “Migrating to vCenter 6.5: Design decisions and important characteristics/limitations to consider”
Great article, I have really enjoyed your article. You show the best practices for vcenter migration.I understood the whole process very well . Thanks for sharing .
But I have a one question , do I need to change the vcenter server licence or not ?
Thx! License will remain the same…
First thanks for your article. I just have one point: I think that enhanced linked mode is mandatory for enabling cross vcenter vmotion. We are currently Windows based vCenter 6 with external PSC in 2 sites, both vCenter being in enhanced linked mode. I understand that I have to chose between Enhanced Linked Mode (and then cross vCenter vmotion) and vCenter HA if I want to migrate to a vCSA 6.5 in both sites….
An external PSC is still required for the enhanced linked mode (and therefore for a cross vCenter vMotion via the web client)
You can do both… the vCenter component will be High available with 3 nodes… it will connect to the PSC as it would have before.
To ensure high-availability of the overall construct a load-balancer in front of the 2 PSC is recommended. Unfortunately you cannot use the internal HA mechanism for external PSC at the current release.
Be aware of that you can do a cross-vCenter vMotion via the new PowerCLI 6.5 R1 even if the vCenter are not within the same SSO-Domain aka. enhanced linked mode
Thank you for your reply…..looks like in our test environment, we are not able to link 2 external PSC when using vCSA for the PSC……We try to get the following topology:
– Site1: external PSC using vCSA model + vCenter using vCSA model, SSO domaine1 and Site1
– Site2: external PSC using vCSA model + vCenter using vCSA model, SSO domaine1 but Site2
This is the topology we have in fact using Windows based PSC and vCenter…We would like to have the same using vCSA. Even if we cannot use the vCSA HA feature (the primary objective is to get rid of the Windows and SQL stuff).
We tried to migrate an existing environment built like that, or to build directly a fresh vCSA environment…no way to link the 2 PSCs so far…..
In the supported topologies for vSphere 6.5, we cannot see any replicated PSC when using vCSA
So is it possible to migrate a Windows based topologie to vCSA when the Windows based topology is using External PSCs being replicated?
Can you draw it into a logical diagram and drop me a mail? From a feature level everything you were able to achieve within the Windows vCenter can be achieved with the vCSA as well.
I had done a similiar setup (in my lab only) with the vCSA 6.0 and it worked fine.
One constraint at the moment is that you cannot relink (move to another PSC) a vCenter connected to a PSC in SITE1 to a PSC in a different SITE2.
Really Good article!!!
Have one query, Can I have vCenter Server Appliance in HA (No Embedded PSC) and have single external PSC which will be enhanced linked mode. I know from this configuration I cannot have HA for PSC but atleast I can achieve Enhanced Linked mode feature. The reason I am asking for Single external PSC is what If I don’t have any supported LB for PSC HA.
That works fine. Just make sure you have ’emergency procedures in place’ in case you are losing the PSC. You can create a backup PSC, join it the existing SSO-Domain in the same site and do a re-point manually.
For sure not optimal. LB version would be recommeneded.
I too am in that situation and I believe it is supported, but not recommended. I have VCSA 6.5 in HA mode but I want to do ELM with another site as well. So I need to break out my embedded PSC and do 2 external PSC at each site. I do not have a load balancer at one site, so I will have to have my HA vCenter pointed to a single PSC, but then I can do a repoint if needed.
I even called VMware support on this, and at first the gentleman stated that yes you must use a LB for your PSC if you are in vCenter HA mode. I questioned why, especially since I have the ability to repoint. After he talked to some people he said it is ok not to have a load balancer. I think its still a bit of a grey area though.
Great article, you know how can I migrate from a embedded 6.0 vcsa to a HA?