Upgrading from vCenter Server Appliance 6.7 to 7.0

In this post we will be going through upgrading from VCSA 6.7 to 7.0. Keeping your appliance at the latest version will give access to new features, feature improvements and security fixes.

When upgrading a VCSA there will be a new appliance VM created. The database and configuration from the existing appliance will be copied during the upgrade process.

Currently in my LAB vCenter Appliance is running 6.7 Update 3l.

Before upgrading to any newer version of VMware it important to check that all products that connect to vCenter (Backup, Reporting or Monitoring tools) all support the latest release.

To check for VMware products you can use the VMware interoperability matrix link below.

VMware Product Interoperability Matrices

This can also be used to view the upgrade path as if you are running 6.0 version of vCenter there is not a direct upgrade to 7.0 and will require a two step upgrade.

There is also a sequence on which products should be upgrade. See below link.

Update sequence for vSphere 7.0 and its compatible VMware products (78221)

For third party (non-VMware) products you will need to check the product support page to verify if the versions are supports with vCenter 7.0

Once everything is confirmed as supported we can go ahead with the upgrade.

First download the 7.0 ISO file from VMware.

Download VMware vSphere – My VMware

Before attempting an upgrade make sure that there is a backup of the appliance that can be used to restore incase of any issue during the upgrade. The source appliance shouldn’t be changed but I would recommend a backup just to be extra safe.

Once download mount the ISO to Windows and go to the \vcsa-ui-installer\win32\ and double click on installer.exe

Select Upgrade

Follow the upgrade wizard

Accept the end user license agreement

Next step needs the vCenter details and the ESXi host or vCenter logons details where the appliance is running. (The hostname of the vCenter was case sensitive and I was getting the below error when using all lower case.)

If a certificate warning appears accept to continue

Give the appliance a name (if you want to re use the existing name the change the current appliances name to something different or there will be an error show when clicking next to continue with the upgrade.)

Select the deployment size

select the datastore

Assign a temporary IP address that will be used while copying data

Review the settings and if all looks to be correct click finish to start the upgrade.

The appliance should now start to deploy

After the deployment of the appliance completes, the next step is to run the configuration stage. This will copy the configuration and data from the existing appliance. Once completed the old appliance will be shutdown.

Click continue to start stage 2 of the upgrade

Click next

There will be a pre-req check done before the upgrade can continue. If there are any errors the upgrade wont be able to procced.

Select the data that will be copied

select if you want to join the customer experience improvement program

Review the settings and tick I have backed up the source vCenter server

Click finish and there will be a warning that the source vCenter will be shutdown

The copy and importing of data can take more than an hour to complete.

Once the upgrade has completed the old appliance should be shutdown and the new appliance running vCenter 7.0 should have all data and configuration copied.

When we logon to the vCenter appliance it will now running 7.0.0

Last step is to verify that all management tools work as excepted after the upgrade.

Configure UnityVSA on VMware 6.7

In the previous post we went thorough configuring and setting up the UnityVSA.

Deploying EMC UnityVSA on VMware ESXi 6.7 – TheSleepyAdmins

In this post we will configure the iSCSI initiators, connecting vCenter to the UnityVSA and configure iSCSI LUN that will be used as shared storage between a LAB virtual ESXi hosts.

First step was to create the iSCSI VMKernal adapter on the ESXi host to allow connection to the Unity.

Logon to vCenter, go to the required host > configure > VMKernel adapters and click Add Networking

Select VMKernel Network Adapter

This image has an empty alt attribute; its file name is image-89.png

Follow the wizard to create the new VMKernal adapter ( I am using the same IP range as my host as this is just a LAB setup but in production this should be a separate physical network)

Next we need to configure the storage adapter, go back to configure > Storage Adapters and click Add Software Adapter

Next we need to configure the adapter settings to point to the SAN in this case the UnityVSA IP.

Once added the adapter will recommend a rescan, we haven’t configure any LUN’s yet so I will do the rescan after that.

Next we need to configure the VMware access and LUN’s on the Unity.

Logon to the web management console > go to VMware > vCenters and click the + button to add the vCenter server

Add in vCenter details, click find and select the required hosts

I wont be creating a VASA provider so I left that un-ticked and completed the wizard

The hosts and vCenter should now show in the Unity console

This image has an empty alt attribute; its file name is image-107.png

Once the host and initiators are added the last step is to configure the LUN’s. This can either be done using block or can be done using VMware storage integration.

If using the VMware integration it will automatically add the datastore to VMware using VMware API’s.

Creating a block LUN is basically the same steps only it doesn’t automate the creation of the Datastore in VMware so in this post we will be using the VMware integration for provisioning LUN’s.

Go to Storage > VMware > Datastores and Click the + button to add

Select block and the VMFS version

Give the datastore a name (This will also be the name that is assigned to the Datastore in VMware)

Select the pool to be used and size of the LUN

Add the hosts that will be configured to access the LUN

I wont be taking snapshots or replication the LUN so I left them un-ticked and complete the wizard

The LUN should now start to be created

There will also be task in VMware showing the Unity starting the rescan of the host HBA’s

If we now check the datastores in VMware the new datastore should show.

VMware and the UnityVSA are now configured and additional LUN can be added to allow for vMotion testing and to setup a cluster as if it where using shared storage.

Deploying EMC UnityVSA on VMware ESXi 6.7

I have been using virtual SAN appliance in my labs for a few years as it is the easiest way to configure shared storage for my LAB cluster and as I don’t have a NAS or another external storage device available.

EMC have a version based on there Unity array and this is the same version we us in production so I wanted to configure this as my virtual SAN.

In the next few posts we will go through configuring a UnityVSA and setting up so that it can present iSCSI LUN’s to VMware.

To download the OVA use the below link, the current version 5.0.3

Data Storage Management Software Downloads | Dell Technologies US

Create a new VM and select deploy using an ova

Select the required datastore

Select the appropriate network

Assign a static IP

This image has an empty alt attribute; its file name is image-66.png

Complete the VM deployment wizard.

The VM will now start to deploy.

Once the appliance was deployed there was no network connectivity and I had to run the intial configuration command.

To connect I used the VMware console. The default logon for the admin account is Password123# but this didn’t work for the console logon.

I had to use service for both the usersname and password.

To configure the IP run the below command.

svc_initial_config -4 “IPAddress Subnet defualtGateway”

I was then able to connect to the Unity Management console. To logon use the default admin/Password123#

Next follow the initial configuration wizard

set the DNS and NTP

Once at the licenses page, we will need the system UUID to be able to register from a trial licenses. The get license didnt work for me so i use

https://www.dellemc.com/en-us/auth/elmeval.htm

Next we configure the storage pools, I added some additional drivers to the VSA to be used as storage pools

Follow the wizard to create the storage pool

This image has an empty alt attribute; its file name is image-98.png

I wont be configure alerts or proxy servers so I leave them as default values.

Next we configure the iSCSI interfaces, these will be used to connect to the ESXi host later

I wont be configuring a NAS server either so will leave that as default also

Finish the configuration

The UnityVSA should now be configured and show simlar to the below.

In the next post we will go through configuring the LUN’s and connecting to vCenter.

Set Custom SSL Certificate on VMware vCenter 6.7 Appliance using Windows CA

In this post we will go through generating and applying a custom SSL cert for VMware vCenter 6.7 Appliance.

When VCSA is installed it generates a self singed cert which cause users to get a cert error when connecting. I used the below VMware doc when setting up the cert.

Replace Machine SSL Certificate with Custom Certificate (vmware.com)

I have already configure a Windows CA so this or another CA will be a requirement before creating the cert.

Before attempting this in production make a backup or take a snapshot to allow quick recovery in case of any issues.

To generate the cert signing request (CSR) , we will use the certificate-manager CLI

To connect I enable SSH on the appliance.

Then used putty client to connect.

First I created a folder that will be used to export the CSR and private key.

Once created we can then run certificate manager using the below.

/usr/lib/vmware-vmca/bin/certificate-manager

We want to replace the Machine certificate with custom cert so select option 1.

Enter the users name and password and select option 1 to generate CSR.

put in the require information below are the fields and values

FieldValue
Countryuse your own country 
NamevCenter FQDN 
OrganizationUse your own company name
OrgUnituse your own 
Stateown state
IPAddressvCenter IP Address 
HostnamevCenter FQDN 
VMCA NamevCenter FQDN 

Once the CSR has been created,

use a client like WinSCP to connect to vCenter and go to the specified folder above in my case this was the cert folder and copy the CSR file.

Now go to your CA to submit the CSR, I will be using the web enrolment.

Click on request a certificate

Click on submit an advanced certificate request.

Click submit a certificate request.

Open the CSR file using notepad and copy the txt

Paste the txt in to the saved request box and select the template I created a custom template for web servers.

Once submitted you should get the option to download the cert selected base 64 encoded as this is required by vCenter.

Once downloaded, upload the cert back to vCenter using WinSCP

Launch certificate manager again and select option 1 but then option 2 to import the custom cert.

/usr/lib/vmware-vmca/bin/certificate-manager

Enter in the details cert file that will be used for vCenter, the private key that was issued with the CSR request and the CA cert file.

You should now the service being updated.

Once completed vCenter should now be using the custom SSL cert.

VMware 6.7 External PSC to Embedded PSC migration

VMware have recently deprecated using external platform service controller (PSC) with vCenter 6.5 Update2 and 6.7

Deprecation of the external Platform Services Controller deployment model (60229) (vmware.com)

Since we where upgrading from Windows vCenter and PSC to appliance’s we had to migrate to new external PSC and then convert the external PSC after the migration.

In this post we will be going through the process of converting and decommissioning an external PSC.

In vCenter 6.7 there is a conversion tool built in to the vCenter web console that allow the PSC to be converted from an external to embedded PSC.

vCenter Server Converge Tool Enhancements in vSphere 6.7 Update 2 – VMware vSphere Blog

The conversion tool is available under Administration > deployments > system configuration

Select the vCenter server that has the external PSC and click converge to embedded

Enter in the logon details for the existing PSC SSO domain and select Join AD if you want to also join the vCenter appliance to AD (use this if the existing PSC has domain joined).

This image has an empty alt attribute; its file name is image-39.png

The converge tools will start and and it will require vCenter servers services to restart, this will cause an outage to vCenter while the service restart.

This image has an empty alt attribute; its file name is image-40.png

Once all the vCenter services have restarted, vCenter should now show as an having an embedded PSC.

The last step is to decommission the old PSC.

Select the old PSC from in the System configuration and use the decommission PSC action.

Click on porceed.

Enter the SSO logon details, view thumbprint and accept the acknowledgment tickbox.

Click decommission and the PSC will start to be removed.

Once completed vCenter will now be running an embedded PSC and the external PSC will be powered off and can be deleted.

If there are other vCenter in enhanced linked mode follow the same process for each additional vCenter

VMware 6.7 PSC Decommission: Failed to get the PSC thumbprint

As part of our recent VMware 6.7 upgrade we where migrating from external PSC to embedded PSC.

All went fine until we tried to decommission the old PSC’s, when trying to view the thumbprint we got the below error:

Failed to get the PSC thumbprint. Ensure PSC port is correct.

With out getting the thumbprint you can’t continue.

We tested accessing the PSC using web browser,

using openssl from the vCenter appliance

openssl s_client -connect PSC01.domain.local:443

We also tested access using telnet to confirm if port 443 was open

curl -v telnet://PSC01.domain.local:443

All test came back fine and there was no ports being blocked.

In the end the issue was caused by using the short name for the vCenter servers https://VCSA/UI

When we changed to the full FQDN, https://VCSA.domain.local/UI this fixed the issue and we where able to complete the decommission. The issue looks to be related to the SAN name on the cert only having the FQDN.

PSC2