When upgrading a vCenter Server appliance that uses an external Platform Services Controller, it is converted to a vCenter Server instance with those services embedded in the appliance. For this reason, you must specify replication partner parameters in the JSON upgrade templates.

When upgrading a vCenter Server appliance that uses an external Platform Services Controller, you must specify replication partner parameters in the JSON upgrade template. These parameters indicate if the upgrade is for one of the following vCenter Server and Platform Services Controller upgrade scenarios.
  • A single vCenter Server and a single Platform Services Controller instance within an SSO domain.
  • The first vCenter Server and Platform Services Controller instance within an SSO domain containing more than one vCenter Server.
  • Replicating vCenter Server and Platform Services Controller instances within an SSO domain, which you must point to an existing vCenter Server 7.0 instance as the replication partner.
Important: It is not possible to upgrade an external Platform Services Controller. The upgrade process converges the Platform Services Controller services into the vCenter Server appliance. For more information, see Removal of Platform Services Controller.

Deployments using an external Platform Services Controller are often called an MxNdeployment, where M represents the vCenter Server, and N represents the external Platform Services Controller. When representing multiple instances of vCenter Server and Platform Services Controller in a domain, this is expressed as MnxNn, where n is the number of instances. For example, M2xN2 indicates two vCenter Server instances and two Platform Services Controller instances within the same domain. When upgrading such a deployment, you first upgrade one instance to version 7.0, and then upgrade the second instance to 7.0, specifying the first of the two instances as the replicating partner.

The replication parameters in the JSON upgrade template are located in the sso section of the template, and are first_instance and replication_partner_hostname.

Parameter Name Description
first_instance The first_instance parameter identifies the vCenter Server as either the first instance in your vCenter Server SSO domain, or as a replicating partner.

If it is the first vCenter Server instance, set first_instance to true For additional instances of vCenter Server in the same SSO domain, set first_instance to false.

replication_partner_hostname*

If you set first_instance to false, you must specify the FQDN or IP address of a vCenter Server that has already been upgraded to version 7.0, and whose external PSC has been converged into the vCenter Server appliance.

When you perform the CLI upgrade of a single vCenter Server appliance that uses an external Platform Services Controller, the process is as follows:
  1. Upgrade the vCenter Server instance in your topology using the vCSA_on_ESXi.json template when upgrading on ESXi, or the vCSA_on_VC.json template when upgrading on a vCenter Server deployment.

  2. For a deployment topology consisting of a single vCenter Server and a Platform Services Controller (an M1xN1 deployment), edit the sso section of the template such that the first_instance parameter is set to true, and remove the replication_partner_hostname parameter.
    "sso": {
    "__comments": [ This is the first instance (M1) vCenter Server management node, with "first_instance" set to "true" and "replication_partner_hostname" removed.
    ],
    "first_instance": true
    }
  3. Specify the remaining upgrade configuration parameters in the JSON template, and upgrade vCenter Server to version 7.0 using the CLI. See Upgrade a vCenter Server Appliance by Using the CLI.
  4. After successfully upgrading vCenter Server, decommission the Platform Services Controller. See Decommission the Platform Services Controller.
    Important: Decommission the Platform Services Controller instances only after upgrading and converging all vCenter Server instances in your topology.
For a deployment consisting of two or more vCenter Server and Platform Services Controller instances (an M2xN2 deployment), you first upgrade the M1 vCenter Server instance to version 7.0, and then upgrade the second, replicating vCenter Server instance.
  1. Upgrade the vCenter Server instances in your deployment using the vCSA_on_ESXi.json template when upgrading on ESXi, or the vCSA_on_VC.json template when upgrading on a vCenter Server deployment.

  2. For the first vCenter Server instance ( M1), edit the sso section of the template such that the first_instance parameter is set to true, and remove the replication_partner_hostname parameter.
    "sso": {
    "__comments": [ This is the first instance (M1) vCenter Server management node, with "first_instance" set to "true" and "replication_partner_hostname" removed.
    ],
    "first_instance": true
    }
  3. For the remaining vCenter Server instance ( M2), edit the sso section of the template such that the first_instance parameter is set to false, and provide the FQDN or IP address of the vCenter Server instance to which you want to replicate the second node. The replication partner is the first vCenter Server instance ( M1) you upgraded to version 7.0, which has been converged with its Platform Services Controller instance.
    "sso": {
    "__comments": [ This is the second instance (M2) vCenter Server management node, with "first_instance" set to "false" and "replication_partner_hostname" set to the hostname of the replication partner.],
    "first_instance": false,
    "replication_partner_hostname": "FQDN_or_IP_address"
  4. Specify the remaining upgrade configuration parameters in the JSON templates, and finish the upgrade using the CLI. See Upgrade a vCenter Server Appliance by Using the CLI.
  5. After successfully upgrading all vCenter Server instances in the topology, decommission the Platform Services Controller instances. See Decommission the Platform Services Controller.
    Important: Decommission the Platform Services Controller instances only after upgrading and converging all vCenter Server instances in your topology.