Perf Best Practices VSphere65

vCenter Lifecycle (Install,
Upgrade, and Migrate)

First Published On: 05-10-2017
Last Updated On: 01-02-2018
1
vCenter Lifecycle (Install, Upgrade, and Migrate)
Table of Contents
1. New Installations
1.1.Overview of vCenter Server Appliance Deployment
1.2.vCenter Server Appliance Embedded Deployment
1.3.vCenter Server Appliance External Deployment
2. Migration to vCenter Server Appliance (VCSA)
2.1.Migration Assistant and Migration Tool
2.2.Migration from vCenter Server 6.0 Embedded to VCSA 6.5
2.3.PSC reconfiguration during migration
2.4.Topology Considerations
3. vSphere 6.5 Upgrade
3.1.vSphere 6.5 Upgrade Considerations
3.2.Top Upgrade Knowledge Base Articles
4. Deployment and Upgrade Planning Tools
4.1.vSphere 6.5 Topology and Upgrade Planning Tool
4.2.vSphere 6.x – Platform Services Controller (PSC) FAQ
4.3.vCenter Server and Platform Services 6.5 Architecture
4.4.vCenter Server and Platform Services Controller Deployment Types
4.5.VMware Platform Services Controller 6.0 Topology Decision Tree
4.6.Product Interoperability Matrix
2
1. New Installations
Guidance and recommendations for new (fresh) installations of vCenter Server
3
1.1 Overview of vCenter Server Appliance Deployment
vCenter Server Appliance Deployment

vSphere 6.5 takes the VCSA deployment experience to the next level. The VCSA 6.5 installer no longer
requires a plugin, making it browser agnostic. If that wasn’t enough, the VCSA installer now supports
use on macOS, Linux, and Window.
Installer
Because the VCSA 6.5 installer no longer requires the Client Integration Plugin (CIP), browser features
such as OVA/OVF import that were dependent on CIP are now native to the VCSA 6.5 installer. Other
CIP provided functions that are now native to the VCSA 6.5 installer include:
• Exporting VM or vApp as an OVF/OVA

• Deploying OVF/OVA from a local file system or URL
• Exporting and importing from Content Library to the local file system
• Downloading and uploading files to and from a datastore
• Connecting remote devices to a VM (CD-ROM, USB, etc.)
A plugin is still needed when enabling Windows Authentication (SSPI) and/or Smart Card
Authentication. The Enhanced Authentication Plugin (EAP) is available to enable these two functions.
Finally, always check the documentation to see supported OS versions. For the best VCSA 6.5 installer
performance check the system requirements.
Deployment
The VCSA 6.0 only had a one stage deployment. This meant any issues which occurred during the
deployment would need a re-deploy. With the VCSA 6.5, a two-stage deployment workflow is now
available. A two stage deployment workflow provides better validation checks during the VCSA
deployment. Stage 1 deploys the VCSA OVA, configures basic networking, and starts the VMware
vSphere Appliance Management Interface (VAMI) service. Stage 2 is the setup and configuration of the
VCSA 6.5. This two stage workflow provides a lot of flexibility that was not possible before:
• The opportunity to take a snapshot between stages, in case any issues occur during Stage 2.
• Staging the VCSA 6.5 deployment and continuing configuration later through the VAMI.
The deployment workflow introduces a new deployment size “X-Large”. With X-Large, the VCSA can
manage up to 2K ESXi hosts and 35K powered on VMs. Also new is the option to increase the Stats,
Events, Alarms, and Tasks (SEAT) storage size. The deployment workflow presents two storage options,
Large and X-Large. The SEAT data storage can be increased at the time of the VCSA deployment or
after.
1.2 vCenter Server Appliance Embedded Deployment
This guide will show how to deploy vCenter Server and the Platform Services Controller components
on a single virtual machine. An embedded deployment is a simple deployment where each vCenter
Sever is individually managed through the vSphere Web Client.
Click to see topic media
1.3 vCenter Server Appliance External Deployment
4
This guide will show how to deploy vCenter Server and the Platform Services Controller components
on their own virtual machines. An external deployment is necessary if Enhanced Linked Mode is a
requirement. Enhanced Linked Mode allows the ability to manage multiple vCenter Servers from a
single vSphere Web Client.
5
2. Migration to vCenter Server

Appliance (VCSA)
Information on planning and performing a migration to the VCSA from Windows vCenter Server.
6
2.1 Migration Assistant and Migration Tool
vCenter Server migrations have typically taken massive planning, a lot of effort, and time. The new
Migration Tool included in the vCenter Server Appliance (VCSA) 6.5 is a game changer. No longer
requiring scripts and many long nights of moving hosts one cluster at a time. The Migration Tool does
all the heavy lifting. Copying the configuration and inventory of source vCenter Server by default. The
migration workflow includes upgrading from either a Windows vCenter Server 5.5 or 6.0 to VCSA 6.5.
Migration Assistant
The first step of the migration workflow requires running the Migration Assistant (MA). The Migration
Assistant serves two purposes. The first is running pre-checks on the source Windows vCenter Server.
The Migration Assistant displays warnings of installed extensions and provides a resolution for each. It
will also show the source and the destination deployment types. Keep in mind changing a deployment
type is not allowed during the migration workflow. More information on deployment type
considerations prior to a migration can be found here. The MA also displays some information about
the source Windows vCenter Server. These included: FQDN, SSO User, SSL Thumbprint, Port, and MA
log folder. At the bottom of the MA is the Migration Steps, which will be available until the source
Windows vCenter Server is shutdown. This is a helpful guide of the migration steps that need to be
completed. The second purpose of the MA is copying the source Windows vCenter Server data. By
default, the configuration and inventory data of the Windows vCenter Server is migrated. The option to
copy historical and performance data is also available. During the migration workflow, no changes are
made to the source Windows vCenter Server. This allows for an easy rollback plan. Do not close the
Migration Assistant at any point during the migration workflow. Closing the MA will result in starting
the entire migration process over. If everything is successful there will be a prompt at the bottom of
the Migration Assistant to start the migration.
Migration Tool
Step two of the migration workflow is starting the wizard driven Migration Tool. This requires the
vCenter Server Appliance 6.5 Installer. Since the identity of the source Windows vCenter Server is
preserved, the migration tool needs to run on a separate Windows Server from the source. Like the
7
VCSA 6.5 Deployment, Migration is also a two stage deployment. The Migration Tool will first deploy a
new vCenter Server Appliance. The new VCSA will have a temporary IP address while the source
Windows vCenter data is copied. The second stage configures the VCSA 6.5 and imports the source
Windows vCenter Server data. This includes the identity of the source Windows vCenter server. The
vCenter Server identity includes FQDN, IP address, UUID, Certificates, MoRef IDs, etc. As far as other
solutions that communicate with vCenter Server nothing has changed. During the migration workflow,
no changes are made to the source Windows vCenter Server. This allows for an easy rollback plan.
Other solutions may require an upgrade, consult the VMware and any third party interoperability
matrixes. Once the migration workflow is completed, login to the vSphere Client and validate your
environment.
2.2 Migration from vCenter Server 6.0 Embedded to VCSA 6.5
This guide will show how to migrate a Windows vCenter Server and the Platform Services Controller
6.0 components on a single virtual machine to a vCenter Server Appliance 6.5.
2.3 PSC reconfiguration during migration
Learn about vCenter Server upgrade and migration, and the use of PSC repointing & reconfiguring
during this process, using an innovative white board format.
2.4 Topology Considerations
This video goes over various topics related to vCenter Server topology. It covers upgrade from vSphere
5.5 to vSphere 6.5, Enhanced Linked Mode, and SSO Domain consolidation, all using an innovative
white board format.
8
9
3. vSphere 6.5 Upgrade

This list of assets assist in planning an upgrade to vSphere 6.5.
10
3.1 vSphere 6.5 Upgrade Considerations
vSphere 6.5 Upgrade Considerations, Part 1

The release of vSphere 6.5 in November 2016 introduced many new features and enhancements.
These include the vCenter Server Appliance (VCSA) now becoming the default deployment. vCenter
Server native high availability, which protects vCenter Server from application failure. Built-in File-
Based backup and restore allows customers the ability to backup their vCenter Server from the VAMI
or by API. The VCSA restore can simply be done by mounting the original ISO used to deploy the VCSA
and selecting the restore option. These features and more are exclusive only to the vCenter Server
Appliance. The new HTML5 vSphere Client is making its first official product debut with vSphere 6.5.
Did someone say security? We now have better visibility of vSphere changes with actionable logging.
VM Encryption allows the encryption of a virtual machine, including disks and snapshots. Secure Boot
for ESXi ensures that only digitally signed code runs on the hypervisor. Secure Boot for VM’s is as
simple as checking a box. We’ve only begun to scratch the surface of all the new vSphere 6.5 features.
Product Education
As you start preparing for your vSphere 6.5 upgrade, a checklist will be the run book used to ensure its
success. The upgrade process can be divided into three phases:
Phase 1: Pre-upgrade – all the upfront work that should be done before starting an upgrade.
Phase 2: Upgrade – mapping the steps of each component that will be upgraded.
Phase 3: Post-upgrade – validation to ensure everything went according to plan.
The first part of any successful upgrade is determining the benefits of the new features and the value
add they will provide to your business. Next is getting familiar with these new features and how they
will be implemented in your environment. The following list will get you started learning each of the
new vSphere 6.5 features and their benefits.
Another consideration to getting familiar with the new features and upgrade process is the hands on
approach in a lab environment. If you have a lab environment at your disposal, try building it as close
to your production environment as possible to simulate both the upgrade process and new feature
implementation. If a lab environment is not available, there are options like VMware’s Workstation or
Fusion if you have the resources to run them. Last, but not least, there is also the Hands on Labs that
11
do not require any resources and provide a guided approach. No matter which option you select, the
key is getting familiar and comfortable with the upgrade process.
Health Assessment
Doing a health assessment of your current environment is critical. Nothing is worse than being in the
middle of an upgrade and having to spending hours troubleshooting an issue only to find out it was
related to a misconfiguration with something as simple as DNS or NTP. Another advantage to doing a
health assessment is discovering wasted resources. For example, virtual machines that are no longer
needed but have yet to be decommissioned. The health assessment should cover all components
(Compute, Storage, Network, 3rd party) that interact with your vSphere environment. Please consult
with your compute, storage, and network vendors for health assessment best practices and tools.
Environmental issues are high on the list when it comes to upgrade show stoppers. The good news is
that they can be prevented.
There are also VMware and community tools that can help by providing reports on your current
environment. Most of these tools come with a 60-day evaluation period, which is enough time to get
the information needed. When using community tools please keep in mind they are not officially
supported by VMware. Finally, there is also the VMware vSphere health check done by a certified
member of VMware’s professional services team. Check with your VMware representative for more
information.
• VMware’s vRealize Operations Manager (60 day evaluation provided)

• vSphere Optimization Assessment (60 day evaluation provided)
12
• VMware {code} vCheck vSphere (community)

• VMware vSphere Health Check (professional services)
• Hardware / Storage / Network / 3rd party (check with each vendor)
Conducting the health assessment could lead to discovering an issue that requires the help of support
and opening a ticket. Do not proceed with the upgrade until all open support tickets have been
resolved. There are instances where an issue can be fixed by applying a patch or an update, but make
sure that any environmental problems have completely been resolved prior to proceeding. This not
only includes VMware support tickets, but also compute, storage, network, and 3rd party that interact
with your vSphere environment.
Important Documents
Now that we’ve learned about the features and completed a health assessment of our current vSphere
environment, it’s time to start mapping out the upgrade process. The first step is looking at important
documents like the vSphere 6.5 documentation, product release notes, knowledge base articles, and
guides. Each of these documents have pieces of information which are vital to ensuring a successful
upgrade. Product release notes, for example, provide information such as what’s new but also
information about upgrades, any known issues, and all key pieces of information. Reading the vSphere
6.5 upgrade guide will give you an understanding of the upgrade process. The VMware compatibility
guide and Product interoperability matrices will ensure components and upgrade paths are supported.
Here is a breakdown of the important vSphere 6.5 documentation that should be viewed prior to
upgrading.
Product Release Notes
• VMware vCenter Server 6.5.0

• VMware vCenter Server 6.5.0 a (Support for NSX 6.3.0)
• VMware vCenter Server 6.5.0 b (Additional functionality added to html5 vSphere
Client)
• VMware vCenter Server 6.5.0 c (Apache BlazeDS security fix)
• VMware vCenter Server 6.5.0 d (New features for vSAN 6.6)
Knowledge Base Articles
• Information before upgrading to vSphere 6.5 (2147548)

• VMware vSphere Upgrade Policies (2149713)
• Update Sequence for vSphere 6.5 and its compatible VMware products
(2147289)
• Best Practices for upgrading to vCenter Server 6.5 (2147686)
• Supported and Deprecated Topologies for VMware vSphere 6.5 (2147672)
• Supported Upgrade paths for vSAN 6.6 (2149840)
• Migrating VMFS 5 datastore to VMFS 6 datastore (2147824)
• Devices deprecated and unsupported in ESXi 6.5 (2145810)
Guides
• Upgrade Guide for vSphere 6.5

• vSphere 6.5 Configuration Maximums Guide
13
• VMware Compatibility Guide (HCL)

• Guest Operating System Installation Guide
• http://partnerweb.vmware.com/GOSIG/home.html
• vSphere 6.5 Security Configuration Guide (Hardening Guide)
Documentation
• VMware vSphere 6.5 Documentation

• VMware Product Interoperability Matrices
Upgrades need to be done with a holistic view from the hardware layer all the way to the application
layer. With this philosophy in mind, a successful upgrade requires advance prep work to be done to
avoid any potential roadblocks. Things like health assessments shouldn’t only be done when preparing
for an upgrade, but also routinely. Think of it as a doctor’s visit for your environment and getting a
clean bill of health. vSphere 6.5 has been released now for six months and since then four patches are
now available providing bug fixes and product updates. The HTML5 vSphere Client now has added
features in the release of vSphere 6.5.0 patch b and vSAN easy install is available in 6.5.0 patch d . This
agile release of patches means customers no longer need to wait on the first update to consider
upgrading to vSphere 6.5. The next few parts in this series will cover mapping out the upgrade process
whiteboard style, architecture considerations for the vSphere Single Sign-On domain, migration, and
upgrade paths.
At this point it is worth noting that the vSphere upgrade process can seem complex if not
overwhelming, especially for our customers who use other tools that depend on vSphere and vCenter
Server. We hear you. VMware is certainly working to make this better. I hope to be able to write about
those improvements in the future. Until then you have upgrade homework to do!
Article: https://blogs.vmware.com/vsphere/2017/05/vsphere-6-5-upgrade-considerations-
part-1.html
Date: 2017-10-26

The first part in this series covered Phase 1 of the vSphere 6.5 upgrade process. Phase 1 consists of all
the upfront work that one should do before starting an upgrade. This includes getting familiar with the
new vSphere 6.5 features and the necessary documents. Hopefully, by now you’ve done your
homework and are ready to move on to Phase 2 which is planning out the upgrade steps of all the
components, scheduling meetings with the business owners to gather requirements, submitting the
necessary change controls, and executing the upgrade.
Over the course of the next couple of parts, we will be going through a couple of scenarios that will
help you see how to plan an upgrade to vSphere 6.5. Each scenario will also include a set of
requirements and decisions used to determine the upgrade path. These examples may or may not
relate to your current environment. The intent is to help familiarize you with the upgrade process and
concepts and then apply them to your specific situation.
Scenario
The Amazing T-Shirt company currently has two datacenter sites, California and New York. The
company recently acquired a third site that will help with their distributions located in Texas. Each site
is running vSphere 5.5 using an embedded vCenter Server deployment on Windows. Other products in
the environment include NSX, vRealize Automation (vRA), vRealize Operations (vROPS), and vRealize
Log Insight (vRLI). vRA is using a separate vCenter Server endpoint from the previously mentioned
vCenter Server. The example chart below represents the current version of each product and target
(upgrade to) version. Accompanying each product are comments taken from the install or upgrade
14
section found in its release notes. Also, do not forget to add any 3rd party products (ex. Backup) that
are in use to determine if they support or have an upgrade path in order to be compatible with
vSphere 6.5.
After reading about all the new vSphere 6.5 features, Adam, the company’s new lead virtualization
architect has decided that it’s time to upgrade. Before starting the upgrade process he has compiled a
list of business requirements and then will map out the associated upgrade path. The vSphere 6.5
upgrade project is estimated to take three months to complete. This includes planning, coordinating,
submitting change controls, and validation. One of Adam’s main objectives is not to over complicate
his design while meeting the business’s requirements. Here is a list of the requirements that Adam has
compiled after his meeting with the business’s key stakeholders.
Requirements and Decisions

vSphere Single Sign-On Domain Consolidation
Having a single vSphere Single Sign-On (SSO) domain will simplify management after the upgrade
process. Starting with vSphere 6.0, licensing, global permissions, custom roles, single sign-on, and
certificates are replicated throughout the SSO domain and make it easier and more efficient to
manage these shared services across multiple vCenter Servers.
• Can only be done in vSphere 5.5

• This will require an architecture change from embedded to external PSC deployment
• Will need to be done prior to the upgrade process
• A separate change control and validation are required
• The outage will only affect IT management of the environment
Enhanced Linked Mode
Today each site is operating autonomously which means each site is managed separately. This is not
efficient for Adam and his team. Their goal is to have visibility to all three sites no matter what vSphere
Client they use.
• Requires external deployment which will be completed with the vSphere SSO domain
consolidation
15
• Automatically inherited when new vCenter Servers are added to the same vSphere SSO domain;
no action required
Migrate to the vCenter Server Appliance
The vCenter Server Appliance 6.5 surpasses its Windows counterpart when it comes to features and
performance. The VCSA is VMware’s direction for vCenter Server and all new features starting with
vSphere 6.5 will only be in the VCSA:
• Native vCenter Server High Availability

• Built-In File-Based Backup Restore
• vSphere Update Manager no longer requires a separate Windows Server
• Supported Migration Tool from Windows to VCSA
High Availability
To meet their current 10 minute RTO Adam has decided to leverage both vSphere HA and vCenter
Server High Availability (VCHA). This will ensure the company is protected from host and vCenter
Server (application) failure.
• vSphere HA will protect again host failure

• vCenter Server VM restart priority setting to highest
• vCenter Server HA requires a load balancer for Platform Services Controller high availability
• Load Balancers supported: F5, NetScaler, and NSX
• VCHA provides 5 minute RTO
Centralized Logging per Site
Currently, there is no centralized logging within each site. The hosts and vCenter Server are using the
default settings and logs are maintained on each individual node. VMware provides a 25-OSI pack with
each vCenter Server license for free.
• No additional cost for logging solution at each site (budget)

• Content Packs available
• Dashboard and Analytics of logging data helpful for troubleshooting
• Not limited to vSphere products, Windows and Linux agents available
• Limited feature set would need to be upgraded to the full version of Log Insight for additional
features such as clustering, event forwarding, archiving, etc.
• More hands on experience with Log Insight and can upgrade in the future as budget permits
Compatibility
Now that Adam has a set of upgrade requirements, the next step is validating the compatibility of each
product. This can be achieved by using the VMware Product Interoperability Matrices which is one of
the documents he is now familiar with as part of his upgrade preparation during Phase 1. Since all the
products communicate with vCenter Server as an end point, it should be selected in step one, labeled
“Select a Solution”. There is the option to list all versions or specify particular version numbers. vCenter
Server will now be displayed in the main horizontal header of the table. The next step is to list other
solutions that will also be upgraded under the “Add Platform/Solution” section. The example below
illustrates both the current version of vCenter Server 5.5 and the version that Adam will be upgrading
to 6.5. Each of the products show the version that Adam plans to upgrade to ensure they are
compatible with vSphere 6.5. As a result, Adam learns that NSX is the only product which has a
requirement of vCenter Server 6.5a (also noted in the release notes), which is the version Adam must
download.
16
Upgrade Order
The final step before performing the upgrade is listing the order of operations. This order is listed in
VMware vSphere upgrade documentation and has not changed over time.
1. vSphere SSO domain consolidation will be the first task that needs to be completed since it is
one of Adam’s requirements. Keep in mind this can only be done on vSphere 5.5 , once the first
node is updated to vSphere 6.5 the ability to consolidate is no longer available. The other item
to note is that this may not be a requirement for everyone. If it is not part of your requirements
then move forward with the next step of upgrading the vCenter Server components. The
following KB provides the details needed to consolidate a vSphere SSO domain in version 5.5.
Also, don’t forget to look at the vSphere 6.5 maximums guide to ensure the supported number
of Single Sign-On servers in a vSphere SSO domain.
17
2. If your deployment is embedded then proceed directly with your vCenter Server upgrade. In
this example, there is an external deployment spanning multiple sites. One of the requirements
is migrating from a Windows based vCenter Server to the vCenter Server Appliance. A
migration also falls under the upgrade category since it is not only copying data (configuration/
inventory by default) from one platform to another (Windows to Photon OS) but also going
from version 5.5 to 6.5. The first step in an external deployment is upgrading or migrating all
the Single Sign-On servers within the vSphere SSO domain first. This will leave the environment
in mixed mode since the Single Sign-On Servers version 5.5 have been upgraded to Platform
Services Controllers version 6.5 and vCenter Servers are still on version 5.5. The migration
process provides an easy rollback plan since the original source machine is not being changed.
This also satisfies the requirement of Enhanced Linked Mode (ELM) because ELM was enabled
through the domain consolidation procedure performed in Step 1.
Note: If Linked Mode is configured in vSphere 5.5, you will have to break it before starting the
migration process.
3. vCenter Server upgrade or migration is next. Now that the environment is in mixed mode it is
important to upgrade or migrate all the vCenter Servers within the vSphere SSO domain as
soon as possible. There is no enforced time limit on mixed mode, but it is better to get both
vCenter Server Components (PSC and vCenter Server) on the same version from a
troubleshooting perspective and to gain all the new functionality in vCenter Server 6.5.
18
Note: The image above is related to the current scenario. The migration tool in vSphere 6.5
supports migrations from both vSphere 5.5 or 6.0.
4. Now that vCenter Server has been migrated to the vCenter Server Appliance 6.5 we can focus
on upgrading the other products in the management plane. Referring back to the chart above
we can determine that the other solutions currently in the environment (NSX, vRA, vROPS) will
need to be upgraded to support vSphere 6.5. This should include any 3rd party products as
well.
5. All ESXi hosts should be upgraded and not left for maximum uptime bragging rights. While
vSphere 5.5 ESXi hosts are supported in a vSphere 6.5 environment, they should not be left as
such. Upgrading the hosts provides support for the latest server hardware, an increase in
scalability, vMotions enhancements, and security improvements. Host upgrades can be
completed by using vSphere Update Manager (VUM) either at the cluster or host level. A
vSphere Update Manager baseline applied at the cluster level can leverage DRS to
automatically move the virtual machines from a host, then place a host in maintenance mode,
and automatically start the upgrade process. Once the upgrade of a host has completed, it will
exit maintenance mode and move to the next host in the cluster until all hosts are within
compliance of the baseline.
6. Virtual Machines need love too!
◦ Having VMware Tools up to date ensures the performance and management of a virtual
machine are enhanced. Although a guest operating system can run without VMware
Tools, failure to install or update a VMware Tools can result in poor operating system
performance and lack of features.
◦ Next is virtual machine hardware, which reflects the supported virtual machine hardware
features. This includes the virtual machine BIOS, the number of supported CPUs and
memory, and the other hardware related features for a virtual machine. The virtual
machine hardware version can remain at the current version and upgraded if newer
hardware capabilities are needed.
7. We can’t forget about storage! vSphere 6.5 introduces VMFS6 which includes many
enhancements over the previous version of VMFS5. VMFS6 now includes automatic space
reclamation at the datastore level as well as from the guest operating system. More information
about all the VMFS enhancements in vSphere 6.5 can be found here . There are multiple
approaches to getting a VMFS datastore to version 6. The first, if space is available, would be to
create a new datastore and Storage vMotion the virtual machines from the existing datastore. If
space is a constraint, then Storage vMotion all of the virtual machines from an existing
datastore then, once empty, upgrade from VMFS5 to VMFS6, and repeat the process until all
datastores have been upgraded.
8. Upgrade vSphere licensing from vSphere 5.x to vSphere 6.x. from the myvmware portal . Apply
the new vSphere 6.x licenses to your vCenter Server and then to your ESXi hosts. There will be a
60 day grace period during the upgrade or migration to allow for the license upgrade.
19
9. Adam will be deploying vRLI to meet his centralized logging requirement at each site. Then we
will configure VCHA to meet his vCenter Server high availability requirement. Any new VMware
or 3rd party products or features can be deployed or configured after the entire upgrade has
been completed.
Adam was able to satisfy the company’s requirements and upgrade successfully from vSphere version
5.5 to 6.5 because he did his due diligence. Keep in mind this is just an example scenario and may or
may not cover your particular environment. Again the important key takeaway is understanding the
upgrade process and concepts and applying them to your own environment . Reviewing the release
notes for each product and knowing not only upgrading process but also known issues is valuable.
Opening an SR with VMware support prior to starting the upgrade process can ensure you’ve validated
the process them and if any issues occur this will expedite the support process. Don’t forget to ensure
that you have a backup prior to starting the upgrade process and also a recovery plan in case you need
to revert back. Making a schedule within the product upgrade chart will also be helpful to determine
not only when a product will be upgraded but also how an upgrade of one product like vCenter Server
will affect other products. In the next part, we will cover another upgrade scenario, this time covering
vSphere 6.0 to 6.5.
part-2.html
Date: 2017-10-26

We’ve started out by discussing the concepts and processes that make up a successful vSphere 6.5
Upgrade. Then it was time to take what we’ve learned in the first part of this series and apply it to a
particular scenario. The first scenario covered upgrading an environment from vSphere 5.5 to 6.5. Now
let’s focus on how to upgrade an environment from vSphere 6.0 to 6.5 Update1. We will be walking
through another example scenario which may or may not cover your particular environment. The key
takeaway is understanding the upgrade process and concepts so you can apply them to your own
environment.
20
Scenario
The Awesome Sticker company has five datacenter sites, three in the US and two in Europe. Each site
is running vSphere 6.0 using the vCenter Server Appliance (VCSA). They are using an external
deployment model for enhanced linked mode. There are three vSphere Single Sign-On domains (SSO)
US, Europe, and VDI. Unlike the other deployments, the VDI environment is using an embedded
Windows vCenter Server. vSAN is the company’s primary storage. The company also uses SRM for
disaster recovery in currently only the US data centers.
Management has tasked Kyle, their new systems engineer, with upgrading the environment to vSphere
6.5. Kyle has already verified the current Dell hardware at each site is compatible with vSphere 6.5
from the hardware compatibility list . He was also proactive and started whiteboarding the upgrade
path of each product.
Environment Discovery
Being new to the environment Kyle wanted to take some time and do an assessment of the
environment. The current environment is running vSphere 6.0 Update 3. Reviewing the release notes,
Kyle notices upgrades from 6.0 Update 3 to vSphere 6.5 are not supported. An avid reader of the
vSphere blog, Kyle learned vSphere 6.5 Update 1 was now available and supports upgrades from
vSphere 6.0 Update 3. He can now proceed with upgrading. He also wanted to take some time and do
an assessment of the environment. Kyle is also planning to setup a meeting with the business owners
of each department. In the meantime he started noting his observations about the environment:
• Each site only has one Platform Services Controller (PSC).

• vCenter Servers at each site are not properly backed up.
• There is a Nexus 1000v running in one of the European data centers.
• Windows vCenter Server used for VDI environment.
• SRM is only used in the US datacenter, no DR solution in the Europe sites.
• Virtual Standard Switches used for host management and vMotion.
• No centralized management of ISOs.
• Clean up of virtual switch port names. Currently, portgroup names are inconsistent and need to
be cleaned up.
21
Requirements and Decisions

External Deployment with single PSC
As noted previously, Kyle observed that there is only a single external PSC at each site and could be a
single point of failure. Kyle is considering changing to multiple PSCs per site. This all comes down to
the availability needs of the company and knowing what role the PSC plays in the environment. The
PSC provides authentication and management of the vSphere SSO domain. We also can’t talk about
availability without mentioning Service Level Agreements (SLAs). The discussion Kyle is having with the
different BUs in the company is a must and will help determine RPO and RTO requirements. All this
information will factor in if a secondary PSC at each site is actually required or an overhead. Let’s
consider what happens when a PSC is not online and its role in the vSphere SSO domain.
• Users cannot login and manage the vCenter Server registered to the PSC that is not online. A
single PSC can have as many as 15 vCenter Server registered in a vSphere 6.5 Update 1 SSO
domain (not recommended). vCenter Server can only be registered with one PSC at a time (1:1).
• Workloads are still running, but no new changes or deployments can take place.
• External PSC is required only for enhanced linked mode, otherwise, use an embedded
deployment.
• Repointing across sites is not supported in vSphere 6.5 – only intra-site. This requires having a
secondary PSC at each site.
• A load balancer provides automatic failover for vCenter Server and other products using PSC
for authentication. The trade-off is the added complexity.
• A load balancer is optional for external deployments without vCenter Server High Availability
(VCHA).
• An external deployment with VCHA requires a load balancer for the PSCs as it’s not aware of
the manual repoint. Also if protecting vCenter Server, PSC should be protected as well.
• Manual repoint of vCenter Server and other products using PSC for authentication via cmsso-
util . The trade-off is manual intervention.
• Linear topology within the vSphere SSO domain, easier to manage and provides no extra
overhead on the PSCs. The recommendation is to create a ring by adding a replication
agreement using vdcrepadmin to have a secondary data path.
• During patching or upgrades repointing can reduce downtime of vCenter Server.
Important resources to help guide with vSphere topology planning and upgrades
vCenter Server Backups

In case of a vCenter Server failure, it is important to ensure a proper backup is available to recover
from. The Awesome Sticker company has a backup team that uses a 3rd party backup product for all
workloads. vCenter Server and PSC were never included as part of the backup solution and schedule.
• Kyle is working with them to ensure it supports VADP (VMware vSphere Storage APIs – Data
Protection) and can take image level backups.
22
• vCenter Server Appliance 6.5 has built-in file-based backup & restore . This supports both
embedded and external PSC deployments.
◦ Backup can be taken while VCSA or PSC is running, no quiescing.
◦ Restore using the VCSA 6.5 ISO which was used to deploy from, no agents needed.
◦ REST APIs available for automation.
◦ Windows vCenter Server for VDI will use 3rd party backup solution for image-level
backups until migrated
Important References for VCSA backups
Network
Kyle noticed there is a Nexus 1000v running in one of the European datacenters. In reading the
vSphere 6.5 Update 1 release notes he discovered this will be the last release to support a 3rd party
switch such as the Cisco Nexus 1000. Kyle has decided to take the opportunity to migrate to the
VMware Virtual Distributed Switch (VDS). He will also use this time to clean up a few other network
items he wants to address.
• He will use the Nexus 1000v to VDS migration tool to move this environment to a Virtual
Distributed Switch (VDS).
• Kyle wrote a powercli script to find any empty portgroups in the environment and plans to have
them decommissioned.
• The portgroups will be renamed to something meaningful since each is listed as portgroup with
a random number.
• vSphere 6.5 allows only unique names across all VDS and Distributed portgroups in the same
network folder. Prior versions of vSphere allowed the same name KB 2147547 .
• Since Kyle is migrating to a VDS he also plans to migrate the management and vMotion
portgroups from a VSS to VDS .
Important References for VDS
• Exporting/importing/restoring Distributed Switch configs using vSphere Web Client

• KB 2120663 Link Aggregation Control Protocol (LACP) with VMware vSphere 5.1.x, 5.5.x and
6.x
• FAQ: Discontinuation of third party vSwitch program (2149722)
Content Management
The company’s ISOs are all over the place and has become a management nightmare. Kyle noticed
that some are placed on different vSAN datastores. Also, the business owners have several stored on
their local machines, taking up large amounts of space. Kyle has been looking at creating a centralized
library and having the different business owners subscribe. He has come up with the following list :
• Implementing Content Library at each datacenter in a subscription model

• vSphere 6.5 uses Content Library as an option to install new operating systems and applications
on VMs using Content Library ISO file option. This will help ensure that ISOs don’t get copied to
a datastore or local machine.
• Business owners can now check their content library before downloading an ISO to avoid
duplicates.
• After ISOs Kyle will look at VM templates. VM templates can be managed by content library,
but currently in OVF format.
Upgrade Order
Kyle opened a proactive SR with VMware Global Support Services (GSS) as the first step in getting
ready for his upcoming upgrade. Since there are three different vSphere SSO domains, Kyle has
decided that he will tackle the smallest footprint and work his way up. His plan of attack starts with the
VDI environment, then the European datacenters, and finally the US datacenters.
VDI Environment
Before starting the VDI environment upgrade Kyle took a backup prior to starting.
23
Note: Run the following script here to get an estimated time of how long the migration process will
potentially take. Add buffer to the estimated time in case of issues.
1. The embedded vCenter Server 6.0 U3 will need to be migrated to 6.5 U1. All of the components
(PSC, VC, VUM) reside on one virtual machine and will be migrated to a VCSA with embedded
PSC. This will be done using the migration tool included in the VCSA 6.5 Update 1 ISO.
2. Upgrade Horizon View server from 7.0 to 7.2. Make sure to upgrade the horizon view
components in the correct order.
3. Use VUM to upgrade the ESXi hosts for the VDI environment.
4. Upgrade VM tools, then upgrade the horizon agent in the virtual desktops.
5. Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native
backup can be done manually or can be automated using the APIs.
European Datacenters
1. Use the Nexus 1000v to VDS migration tool and complete network cleanup tasks.
2. Backup the PSCs and vCenter Servers prior to upgrading. Yes, you can take a snapshot, but
there is no need to shut down all the PSCs to do so. Remember the PSCs are multi-master so all
the information is replicated across the vSphere domain.
3. Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case, we
only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and
selecting the upgrade option from the installer menu and go through the wizard to upgrade the
PSCs. Now that the environment is in mixed mode and it is important to upgrade all the vCenter
Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced
time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and
vCenter Server) on the same version from a troubleshooting perspective and to gain all the new
functionality in vCenter Server 6.5.
4. Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1
by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
5. Since there are only two PSCs, one at each site we will have to make sure that we clean up some
replication agreements once we are done using vdcrepadmin . This will also give Kyle the ability
to manually repoint within each site in case of a PSC failure. Although he liked the idea of the
automated failover using the load balancer, he didn’t want the added complexity it brings.
◦ Original PSC #1 in the London site connected to original PSC #2 in the Berlin site.
◦ Deploy a new secondary PSC # 2 in the London site London, replication partner is the
original PSC # 1 in the London site.
◦ Deploy new a secondary PSC #2 in the Berlin site, replication partner is the original PSC
# 1 in the Berlin site.
◦ Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Berlin site
to PSC # 1 in the London site.
◦ Clean up old replication agreement between original PSC #1 in the London site and
original PSC #1 in the Berlin site.
24
6. Upgrade vSAN .
7. Upgrade SRM .
8. Upgrade ESXi hosts using VUM.
9. Upgrade VM tools / compatibility.
10. Upgrade VMFS.
11. Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup . The native
backup can be done manually or can be automated using the APIs. You only need to backup
one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The
restore process of a PSC is only required if they all go down otherwise just deploy new.
US Datacenters
1. Complete network cleanup tasks.

2. Backup the PSCs and vCenter Servers prior to upgrading. Yes, you can take a snapshot, but
there is no need to shut down all the PSCs to do so. Remember the PSCs are multi-master so all
the information is replicated across the vSphere domain.
3. Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case, we
only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and
selecting the upgrade option from the installer menu and go through the wizard to upgrade the
PSCs. Now that the environment is in mixed mode and it is important to upgrade all the vCenter
Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced
time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and
vCenter Server) on the same version from a troubleshooting perspective and to gain all the new
functionality in vCenter Server 6.5.
4. Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1
by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
5. Add a secondary PSC at each site, one at each site we will have to make sure that we clean up
some replication agreements once we are done using vdcrepadmin.
◦ Original PSC #1 in the Seattle site connected to original PSC#2 in the Austin site.
◦ Original PSC#2 in the Austin site connected to the original PSC in the Tampa site.
◦ Deploy a new secondary PSC # 2 in the Seattle site, replication partner is the original
PSC # 1 in the Seattle site.
◦ Deploy a new secondary PSC #2 in the Austin site, replication partner is the original PSC
# 1 in the Austin site.
25
◦ Deploy a new secondary PSC #2 in the Tampa site, replication partner is the original PSC
# 1 in the Tampa site.
◦ Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Tampa site
to PSC # 1 in the Seattle site for the ring.
◦ Create a new replication agreement between newly deployed PSC #2 in the Seattle site
with PSC #1 in the Austin site.
◦ Create a new replication agreement between newly deployed PSC #2 in the Austin site
with PSC #1 in the Tampa site.
◦ Clean up the old replication agreement between original PSC #1 in the Seattle site and
the original PSC #1 in the Austin site.
◦ Clean up the old replication agreement between the original PSC #1 in the Austin site
and the original PSC # 1 in the Tampa site.
◦ Use vdcrepadmin to validate you have nice linear topology
◦
6. Upgrade vSAN
7. Upgrade SRM.
8. Upgrade ESXi hosts using VUM.
9. Upgrade VM tools / compatibility.
10. Upgrade VMFS.
11. Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native
backup can be done manually or can be automated using the APIs. You only need to backup
one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The
restore process of a PSC is only required if they all go down otherwise just deploy new.
Validation
Kyle kept the business owners in the loop during the entire upgrade process. This started from the
initial meeting to explain what the upgrade process was and what it would mean to them. The
meetings also serve as a vehicle to interview the business and get a sense of their current issues and
requirements. Kyle was also proactive having the business owners test their applications in a vSphere
6.5 Update 1 lab environment. This was also documented in the details of change control Kyle
submitted. The change control also included a rollback plan and what testing the business owners
would do in their validation testing. Once the business owners signed off on their application, Kyle was
able to move to the next environment.
Conclusion
Kyle was tasked with upgrading an environment from vSphere 6.0 U3 to vSphere 6.5 Update 1. Before
starting he did his research getting up to speed on what’s new with vSphere 6.5 Update 1. He also
watched the new vCenter Server light board videos to learn about vCenter Server architecture,
deployment, and availability as part of this upgrade process. Since vCenter High Availability was not a
requirement, Kyle was able to add a secondary PSC at each site without the required load balancer
reducing complexity. He backed up prior to starting the upgrade process and had a recovery/backout
plan in case he needed to revert back. The important key takeaway is understanding the upgrade
process and concepts and applying them to your own environment. Happy upgrading!
part-3.html
26
Date: 2017-10-26
3.2 Top Upgrade Knowledge Base Articles
Top Upgrade Knowledge Base Articles

Title Description
This article covers the procedure that can be

How to repoint and re-register vCenter Server used when preparing for a vSphere 5.5 to 6.5
5.1 / 5.5 and components (2033620) upgrade where vSphere SSO Domain
consolidation is required.
This article describes the currently supported

and deprecated topologies in vSphere 6.5. This
Supported and deprecated topologies for
should be a reference when planning the
VMware vSphere 6.5 (2147672)
desired vSphere SSO Domain and vCenter
Server 6.5 architecture.
Best practices for upgrading to vCenter Server This article should be reviewed before planning
6.5 (2147686) a vSphere 6.5 upgrade.
This article provides scripts and procedures in

Estimating the time for migration of vCenter
order to estimate the downtime and migration
Server 5.5 or 6.0 to vCenter Server Appliance
time involved when migrating to the vCenter
6.5 (2147711)
Server Appliance 6.5.
27
4. Deployment and Upgrade Planning

Tools
Use these tools to help you architect your vCenter Server deployment and plan for an upgrade to the
latest version.
28
4.1 vSphere 6.5 Topology and Upgrade Planning Tool
Click to see the content
29
4.2 vSphere 6.x – Platform Services Controller (PSC) FAQ
vSphere 6.x – Platform Services Controller (PSC)

FAQ
The following questions and answers apply to both vSphere 6.0 and 6.5.
Question Answer
Architecturally, PSC is the same across 6.x releases. In vSphere 6.0 the
limit was 4 vCenter Servers per PSC. This limit imposed some design
constraints and could cause some additional complexity. However,
there is no longer a maximum number of vCenter Servers per PSC. In
6.5 the maximum number of vCenter Servers within a single vSphere
SSO Domain (currently 10) can be supported by a single PSC. This
simplifies the architecture and enables you to deploy a pair of PSCs in
What changes are there
each physical site to support up to the maximum number of vCenter
between vSphere SSO
Servers in a vSphere SSO Domain. You could also choose a topology
Domains and PSC from
where each vCenter Server has its own external PSC. This means there
6.0 to 6.5?
would be 10 vCenter Servers and 10 external PSCs. More than 10 PSCs
is not supported in a single vSphere SSO Domain.
PSCs are now also deployed with 4 GB of RAM by default (6.0 U3+ and
6.5 GA+) whereas in 6.0 U2 and prior they only had 2 GB. This could
cause excessive swapping. 4 GB should be enough for most
circumstances and it should not be changed unless advised to do so by
VMware.
We still do not have public latency numbers but we are working on

What is the latency
publishing detailed figures in the future. We recommend a maximum
requirement between
latency of 100 ms RTT between nodes. There is a noticeable drop off
PSCs and vCenter
in performance once the latency goes above 100 ms RTT. This will
Servers for Enhanced
affect login times, inventory searches, and UI latency when managing
Linked Mode?
objects in remote vCenter Servers.
If you want/need Enhanced Linked Mode (e.g. multiple vCenter Servers

When should I use an
in the same vSphere SSO Domain) you have to use an external PSC. As
Embedded PSC vs
of 6.5 GA, we no longer support embedded PSCs with Enhanced
External PSC?
Linked Mode.
There could be a product that recommends and external PSC for some
reason. But outside of that there is really no benefit to running an
Is there a reason to use
External PSC without Enhanced Linked Mode. The performance
an External PSC even if
impact on vCenter Server is very low for an Embedded PSC and it can
I'm not going to use
also be used with vCenter HA. If you are using an External PSC with
Enhanced Linked
vCenter HA a supported Load Balancer is REQUIRED which
Mode?
complicates things unnecessarily if Enhanced Linked Mode is not
being used.
Do I really have to use a Yes. First, why would you want a single point of failure (PSC) to be used
Load Balancer if I'm as a dependency for a highly available vCenter Server? Second, it just
using vCenter HA with won't work without the load balancer. Repointing the Active node of a
an External PSC? VCHA cluster to a different PSC is unsupported.
30
If you have external solutions, for example SRM and/or NSX, a load
balancer will reduce the disruption if a PSC fails. Not only you have to
Is there any other repoint vCenter Server to another PSC within the same SSO Site (6.5
reason to use a Load only) but they would also have to reconfigure those external solutions
Balancer for my to point to the other PSC as well. So, while it does take some extra
external PSCs? work to deploy and configure, it may be better in the long run and less
disruptive to more than just vCenter Server in the event of a PSC
failure.
Repointing Across Sites – In vSphere 6.5 there is a limitation where a

vCenter Server cannot be repointed to a PSC in a different SSO Site.
We are evaluating changes to this behavior based on feedback
What is the current
received from customers.
status of operations
SSO Domain Consolidation - There is currently no way to combine,
involving SSO Domains
merge, or otherwise connect two different vSphere SSO Domains. This
such as repointing,
has been a very common request and functionality to address these
merge/consolidation,
use cases is being discussed and evaluated.
and moving vCenter
Moving between vSphere SSO Domains - There is currently no
Servers between
supported way to move a PSC or vCenter Server from one vSphere
vSphere SSO Domains?
SSO Domain to another vSphere SSO Domain. This is something that is
being discussed and we are making efforts to bring this capability into
the product.
PSCs always need to be upgraded/updated/patched first prior to

performing the same on a vCenter Server. All PSCs in the vSphere SSO
Domain must be updated and should be updated as close to each
other as possible (within the same maintenance window). Once all
What is the upgrade PSCs are updated then the vCenter Servers can be updated. For
order when upgrading example, when patching from 6.5 GA to 6.5.0a you need to patch all
or patching vCenter PSCs in the vSphere SSO Domain prior to patching any of the vCenter
Server and PSCs? Servers. For more information about what happens when you have
vCenter Servers with mixed versions such as some on 6.5 and some on
6.0 please see this blog post: https://blogs.vmware.com/
vsphere/2017/09/understanding-the-impacts-of-mixed-version-
vcenter-server-deployments.html
If you are currently running multiple embedded SSO instances (5.5) or

If I'm going to upgrade embedded PSCs (6.0) in a single vSphere SSO Domain, you need to
to vSphere 6.5 and I move to an external SSO/PSC model first. Embedded PSC replication
want to migrate to an in 6.5 is not supported so, in order to make sure you are completely
external PSC for supported throughout the upgrade process, our recommendation is to
Enhanced Linked Mode, move to an external SSO/PSC first and then upgrade.
should I do that before If there are only standalone vCenter Servers with embedded SSO/PSC
or after the upgrade? then you can upgrade first and then reconfigure to an external PSC
once the vSphere 6.5 upgrade is complete.
How should I plan to

manage SSL certificates
Please review this blog post: http://vmware.com/go/hybridvmca
in my vSphere 6.x
environment?
For additional technical questions and answers specifically for vSphere 6.0, please review FAQ:
VMware Platform Services Controller in vSphere 6.0 (2113115) .
4.3 vCenter Server and Platform Services 6.5 Architecture
31
In this video we have a deep dive discussion on the vSphere Sign Sign-On domain components and
what role they play. We also cover terminology, decommission, and backup of these components.
4.4 vCenter Server and Platform Services Controller Deployment

Types
This video covers vCenter Server and Platform Services Controller 6.5 deployment types. Here we
address common questions such as when should embedded or external deployments be used. We also
debunked some misconceptions about the embedded deployment type and enhanced linked mode.
4.5 VMware Platform Services Controller 6.0 Topology Decision Tree
4.6 Product Interoperability Matrix
32
33

Perf Best Practices VSphere65

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Perf Best Practices VSphere65

Загружено:

Авторское право:

Доступные форматы

vCenter Lifecycle (Install,

Upgrade, and Migrate)

1.1 Overview of vCenter Server Appliance Deployment

vCenter Server Appliance Deployment

• Exporting VM or vApp as an OVF/OVA

1.2 vCenter Server Appliance Embedded Deployment

Click to see topic media

1.3 vCenter Server Appliance External Deployment

Click to see topic media

2. Migration to vCenter Server

2.1 Migration Assistant and Migration Tool

2.2 Migration from vCenter Server 6.0 Embedded to VCSA 6.5

Click to see topic media

2.3 PSC reconﬁguration during migration

Click to see topic media

2.4 Topology Considerations

Click to see topic media

3. vSphere 6.5 Upgrade

3.1 vSphere 6.5 Upgrade Considerations

vSphere 6.5 Upgrade Considerations, Part 1

Phase 3: Post-upgrade – validation to ensure everything went according to plan.

• VMware’s vRealize Operations Manager (60 day evaluation provided)

• VMware {code} vCheck vSphere (community)

Product Release Notes

• VMware vCenter Server 6.5.0

Knowledge Base Articles

• Information before upgrading to vSphere 6.5 (2147548)

• Upgrade Guide for vSphere 6.5

• VMware Compatibility Guide (HCL)

• VMware vSphere 6.5 Documentation

vSphere 6.5 Upgrade Considerations, Part 2

Requirements and Decisions

• Can only be done in vSphere 5.5

Enhanced Linked Mode

Migrate to the vCenter Server Appliance

• Native vCenter Server High Availability

• vSphere HA will protect again host failure

Centralized Logging per Site

• No additional cost for logging solution at each site (budget)

vSphere 6.5 Upgrade Considerations, Part 3

• Each site only has one Platform Services Controller (PSC).

Requirements and Decisions

vCenter Server Backups

Important References for VCSA backups

Important References for VDS

• Exporting/importing/restoring Distributed Switch conﬁgs using vSphere Web Client

• Implementing Content Library at each datacenter in a subscription model

1. Complete network cleanup tasks.

3.2 Top Upgrade Knowledge Base Articles

Top Upgrade Knowledge Base Articles

This article covers the procedure that can be

This article describes the currently supported

This article provides scripts and procedures in

4. Deployment and Upgrade Planning

4.1 vSphere 6.5 Topology and Upgrade Planning Tool

Click to see the content

Click to see the content

4.2 vSphere 6.x – Platform Services Controller (PSC) FAQ

vSphere 6.x – Platform Services Controller (PSC)

We still do not have public latency numbers but we are working on

If you want/need Enhanced Linked Mode (e.g. multiple vCenter Servers

Repointing Across Sites – In vSphere 6.5 there is a limitation where a

PSCs always need to be upgraded/updated/patched ﬁrst prior to

If you are currently running multiple embedded SSO instances (5.5) or