Skip links

Migrate vCD 9.5 Linux Instance to vCD 9.7 Appliance

Author: Published on: Published in: VMware

This post deals with the migration of a vCD 9.5 Linux instance with external MS SQL DB to a vCD 9.7 Appliance with internal postgres.

The process for migration to an appliance requires that the existing 9.5 instance be upgraded along with the SQL DB before migrating to a new 9.7 appliance with internal Postgres DB. For this upgrade I will be using the latest build at the time of writing for vCD 9.7.
I first download the Linux Upgrade bin file as well as the Virtual Appliance Installation ova file required.

First Step: Upgrade vCD 9.5 to 9.7

To recap, the config of the current environment is that I have one vCD 9.5 Linux Cell with an external MSSQL DB.

Cell Name: sto-vcd95-01.terataki.local

  • IP1: 172.16.50.18/24 – Used for HTTP Access
  • IP2: 172.16.50.19/24 – Used for Console Proxy

MSSQL DB Server Name: sto-db01.terataki.local

  • IP: 172.16.50.15/24

The vCD instance has 2 simple Organisations set up.

I make sure that I have backed up both the Cell and the DB Server and taken snapshots. I also carried out a simple backup from within SQL Studio on the vCloud database.

Using WINSCP I connect to the existing 9.5 cell and copy over the recently downloaded upgrade bin file to a directory I created earlier. In this case it is the vmware-vcloud-director-distribution-9.7.0.16082348.bin that I require.

Running the upgrade

SSH to the cell, change to the directory where the bin file has been copied to and change the permissions on the newly copied file

# chmod u+x vmware-vcloud-director-distribution-9.7.0.16082348.bin

begin the upgrade by running

# ./vmware-vcloud-director-distribution-9.7.0.16082348.bin

A few pre-checks occur as well as unpacking of the required files. The installer asks if I wish to continue with the upgrade of the cell. To do so press Y. As this is a lab I can ignore the warning about the memory being less than is required. In the real world this should be addressed. The cell will enter maintenance mode, this is OK in this environment, and begin upgrading the code.

Once complete the installer asks me now to update the MSSQL DB schema. To do so I need to enter the command

# /opt/vmware/vcloud-director/bin/upgrade

The installer connects to the MS SQL DB and carries out some checks. As this is a small environment and I proceeded quickly up to this point I get a a warning about the cell not appearing to be in a state for upgrade. This is because the status can take a few minutes to be detected. Here I only have one cell I know is OK so I press Y to ignore and proceed.

The DB schema takes a few moments to update. Once finished the installer asks if I want to start the vCD services. Press Y if so. It takes a few seconds for the services to start. These can be checked by running

# service vmware-vcd status

Once the services are started I can log into the vCD UI. I observe that my Organisations are still there as well as other customisations. Checking the about menu item we see that the instance (sto-vcd95-01) is now upgraded to 9.7.

Second Step: Deploy 9.7 Appliance

With the Cell successfully updated I am now ready to begin the install of the new 9.7 appliance that I will eventually migrate to. In order to keep things simple in the lab I am using new IPs for the appliance although there is an option to change the existing cell to use temporary IPs in order that the the new appliance ultimately use the cells old IPs.

For this deployment I will use a small appliance with the following details

Appliance Name: sto-vcd01.terataki.local

1 vNIC with 2 IPs

  • IP1: 172.16.50.20/24 – Used for HTTP and Console Access
  • IP2: 172.16.50.21/24 – Used for DB

Third Step: Commence Migration

Once the appliance has been deployed, started and run through its initial configuration I can log into the vami interface on https://172.16.50.20:5480 to check that it deployed correctly. There is no need to run through the config of the cell further.

Now I need to SSH to both the upgraded cell and the new 9.7 appliance and stop the services on both by running

/opt/vmware/vcloud-director/bin/cell-management-tool -u administrator cell –-shutdown

With both the source and destination stopped I goto the destination appliance (172.16.50.20/24) and allow access to the postgres DB (172.16.50.21/24) from the old linux cell (172.16.50.18/24).

To do this we can create a file in the /opt/vmware/appliance/etc/pg_hba.d/ directory containing text in the following format:

host   vcloud    vcloud  172.168.50.18/24   md5

Once that is done the entries are dynamically appended to the pg_hba.conf file, which controls the access to the primary database in the HA cluster.

After the access to the postgres DB has been updated I can jump back to the source cell and run the command to connect to the target postgres DB (172.16.50.21) and migrate data over from MS SQL. The command to do so:

/opt/vmware/vcloud-director/bin/cell-management-tool dbmigrate -dbhost 172.16.50.21 -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword vcloudpass

Depending on the size of the DB this could take a few moments.

Now the DB has transferred over there are a few additional steps required in order that the new cell can be used.

Final step

We need to back up the properties and the certificates files on the new appliance and copy and replace these files from the migration source. All the files are located in  /opt/vmware/vcloud-director/etc/

The files required are

  • global.properties, 
  • responses.properties, 
  • certificates,
  • proxycertificates 
  • truststore*
    *If you are migrating to vCloud Director version 9.7.0.1 or later, you must also back up, copy, and replace the truststore file.

Also back up the keystore file that is at /opt/vmware/vcloud-director/certificates.ks.
Do not copy and replace with the keystore file from the migration source.

Run the command to reconfigure the vCloud Director service.

/opt/vmware/vcloud-director/bin/configure --unattended-installation --database-type postgres --database-user vcloud --database-password vcloudpass --database-host 172.16.50.21 --database-port 5432 --database-name vcloud --database-ssl true --uuid --keystore /opt/vmware/vcloud-director/certificates.ks --keystore-password VMware123! --primary-ip 172.16.50.20 --console-proxy-ip 172.16.50.20 --console-proxy-port-https 8443 /opt/vmware/vcloud-director/bin/configure --unattended-installation --database-type postgres --database-user vcloud --database-password vcloudpass --database-host 172.16.50.21 --database-port 5432 --database-name vcloud --database-ssl true --uuid --keystore /opt/vmware/vcloud-director/certificates.ks --keystore-password VMware123! --primary-ip 172.16.50.20 --console-proxy-ip 172.16.50.20 --console-proxy-port-https 8443

Now the cell has started the services, and I have verified this in the CLI by running

# service vmware-vcd status

I can proceed to the new URL of the appliance and check that I see my vCD instance, and that all the settings I configured previously have been migrated over.

At this point the original source instance has successfully been migrated over to a new 9.7 appliance with internal postgres DB. The old instance can be shutdown.

Documentation

Configure External Access to the vCloud Director Database

Migrating vCloud Director with an External Microsoft SQL Database to vCloud Director Appliance

Leave a Comment