In a previous post I outlined how to migrate your existing vCloud SQL Database over to a PostgreSQL Database. It’s not too difficult but you do need to deploy and configure the PostgreSQL server itself first, so there are a few steps involved. Then I thought what about the people that haven’t moved over to PostgreSQL and have stayed with the traditional SQL server database? Seeing as vCloud Director 9.7 will be the last version to support SQL what are their options and can they just skip this step all together and move directly to the appliance?
Luckily the answer is yes!
Currently in my lab I have vCloud Director 9.5 installed on a CentOS 7 VM with an external SQL Database running on a SQL 2016. In this post I will go through the four main steps you need to complete to migrate over to the new vCloud Director 9.7 Appliance.
1 – Upgrade the existing instance of vCloud Director
2 – Deploy the new vCloud Director 9.7 Appliance
3 – Migrate the external SQL Database to the embedded PostgreSQL Database
4 – Copy the shared transfer service data and certificate files to the Appliance
As with any upgrade or migration make sure you have a valid backup of the VM (Use Veeam Community Edition, its free!) and you also take a separate backup of the database on the SQL Server. Then take a snapshot before you get started just to be sure.
The first step is to upgrade vCloud Director 9.5 to 9.7 on the CentOS VM.
In order to upgrade vCloud we first need to stop the services. SSH into your vCloud cell and run the following command,
service vmware-vcd stop
Then use winscp to copy the install file over to your existing cell. Then we need to switch to the location that we have the install file saved and run the following command to make the file executable,
chmod u+x vmware-vcloud-director-distribution-9.7.0-12990033.bin
You will then notice that the installation file now displays in green text and is ready to be installed.
Run the following command to start the installation,
./vmware-vcloud-director-distribution-9.7.0-12990033.bin
Type Y and hit Enter to start the upgrade
The upgrade from vCloud 9.5 to 9.7 is now complete
Once the vCloud Upgrade has completed its time to upgrade the database. For this example the DB is hosted on my SQL 2016 server so once again before you do this ensure you have taken a backup of the DB just in case.
Type the following to start the DB upgrade,
/opt/vmware/vcloud-director/bin/upgrade
Enter Y to continue
Before the upgrade starts it will prompt you again to make sure you have backed up your database. Enter Y to continue
Enter Y to start the services
Both the vmware-vcd-watchdog and the vmware-vcd-cell services should now start
Wait a few minutes for the services to start up before attempting to login
If you check the About section you will see that vCloud Director has been upgraded to 9.7
The second step is to deploy the new vCloud Director 9.7 Appliance
The vCloud Appliance contains the VMware Photon OS, vCloud Director Services and PostgreSQL 10
Before we get started make sure you have created the required DNS entries for eth0 and eth1, both forward and reverse lookup. We will also require an NFS share to mount as the transfer store. You can do this by deploying an openfiler server and presenting the NFS share or presenting the share from a filer in your environment. If you are also just testing this out in the lab then the easiest way is to present it from a windows server.
You can do that by opening up Server Manager and selecting Add roles and features. Click next through the wizard until you reach the Server Roles section, then expand File and Storage Services, expand File and iSCSI Services and tick the box for Server for NFS. Then click Add Features on the window that appears, then click Next, then Next again and Install
Once that is complete create a folder on the windows server that you want to use as the transfer store. Then right click the folder and select properties and click on the NFS Sharing tab. Then click Manage NFS Sharing
Then tick Share this folder and enter the share name, I have just entered vcloud for this example. Then click Permissions
Then change the Type of Access to Read-Write and tick Allow root access and click OK
Then click OK again to close the NFS Advanced Sharing box and click Close on the folder properties. The NFS share is now created and ready to be used during the ova deployment.
I have created another DNS entry to reference this server so the new mount path will look like this,
labnfs.stevenonofaro.local:/vcloud
Now it’s time to deploy the ova file. Login to your vCenter server and choose the appliance ova file and click Next
Enter the VM Name and click Next
Select the compute resource and click Next
Review Details and click Next
Accept the License Agreement and click Next
Select your configuration size, there are 5 options available. For this example I will be using Primary – small. Once you have made your selection click Next
Select your disk format and storage, then click Next
Select which networks you will be using for each adapter.
In production these should be placed on separate networks. The Eth0 Network is used for the HTTP traffic and the console proxy service on custom port 8443. Eth1 Network is used for vPostgreSQL, so having them on separate networks splits the traffic and helps to avoid duplicate entries in the route table.
For this example in my lab I have used two separate port groups to illustrate this.
Next up is the Customize template section and you will have to scroll down and complete each of the options. I have put together an expanded view with all of the options I used during the deployment.
The entries below a pretty standard for an ova deployment but I just want to outline a few which can cause you a few issues if set incorrectly.
Expire Root Password Upon First Login – Untick this box then you can use the password you set instead of having to reset it when you first login.
Enable SSH Root Login – Enable this option to assist with testing once the appliance is deployed.
NFS Mount for Transfer File Location – The format for this needs to be set as the IP/DNS name of the server hosting the service and then the mount path. Earlier we presented an NFS share from a windows server so I have used labnfs.stevenonofaro.local:/vcloud
The “vcloud” part at the end is just the NFS share name. Another good option for this it so deploy Openfiler and then present the NFS share. I have tested with both and can confirm either one works fine.
Installation ID – If you are deploying the appliance at a new site and are looking to configure multisite later on update this entry from 1 to 2 for example.
Static Routes for Eth0 and Eth1 – Since this is in my lab and I have both on the same subnet, including the NFS share this can be left blank. In production this would need to be configured when trying to communicate with external services.
Domain Name – The entry says the domain name of this VM. For this just enter the domain name itself, so my labs domain is stevenonofaro.local. Make sure this one is correct otherwise services can fail to start and you will have issues connecting to the PostgreSQL DB.
Domain Search Path – Then again for this entry use the domain name in your lab/production environment. So I have used stevenonofaro.local here also.
Once complete click Next to continue
Review the settings and click Finish
Next SSH into the newly deployed appliance with the password used during the deployment. If you did leave the expire password on first login box selected you would be prompted here to change it. If not you would just login as normal.
Now it’s time to check the services are running correctly. The two main services you want to check are the vCloud Services and the PostgreSQL Services.
Enter the following to check the vCloud Director Services – service vmware-vcd status
Then if that comes back as active (running) just like the image below then check the PostgreSQL Service.
Enter the following to check the PostgreSQL Services – service vpostgres status
You can then log into the management interface of the appliance on port 5480,
https://labvcd97.stevenonofaro.local:5480
You should see the server Name LABVCD97 with the Role set to primary and a Status of running. If this is not the case then you can check the following log files to help you troubleshoot the issue.
/opt/vmware/var/log/firsboot
/opt/vmware/var/log/vcd/setupvcd.log
/opt/vmware/var/log/vami/vami-ovf.log
You can also run the command ovfenv to double check all of the entries used when you were configuring the appliance.
If all looks well you should be able to access the vCloud Director logon prompt using your dns name followed by /cloud
https://labvcd97.stevenonofaro.local/cloud
Or the HTML5 interface using https://labvcd97.stevenonofaro.local/provider
The third part is Migrating the existing SQL DB over to the embedded PostgreSQL database on the appliance
We need to stop the vCloud services on each of the cells (existing and new)
First on the new appliance,
service vmware-vcd stop
Then SSH to the original vCloud cell and stop the services also
Now we need to configure the external access to the embedded database running on the vCloud Appliance. This will allow the existing vCloud cell to connect to the appliance database.
SSH to the newly deployed appliance and browse to the following location,
cd /opt/vmware/appliance/etc/pg_hba.d/
Then create a new txt file here by entering vi external.txt
My original vCloud cell IP is 192.168.1.61 so enter the following txt to allow the cell access to the embedded database
#TYPE DATABASE USER ADDRESS METHOD
host vcloud vcloud 192.168.1.61/24 md5
When you are ready to save the file hit escape then type :wq and press enter
If you type ls and hit enter you will now see the newly created txt file in the directory
The entries added to this file are dynamically updated to the pg_hba.conf file which controls access to the database. Now if you want to check that your entry was actually added to the pg_hba.conf file then browse to the following location,
cd /var/vmware/vpostgres/10/pgdata
Then if you use the ls command you should see the pg_hba.conf file located within this directory. This file controls access to the PostgreSQL instance.
Type the following,
cat pg_hba.conf to view the file
You will see the new entry has been automatically added to the bottom line of the pg_hba.conf file
Now let’s migrate the database from the original vCloud Cell over to the New Appliance. Currently my original vCloud cell is running on CentOS 7 and the database is still on a SQL 2016 Server. I could migrate the DB to a PostgreSQL server first to make my life easier but I am keen to see if this will work.
SSH to the original cell and run the following command
/opt/vmware/vcloud-director/bin/cell-management-tool dbmigrate -dbhost 192.168.1.85 \ -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword P@ssw0rd
The command is basically saying migrate the Source DB of this original cell to the PostgreSQL DB via the ETH1 interface (192.168.1.85) using the database information we entered when deploying the new appliance. If all goes well you should see the Database Migration Succeeded with a failed and skipped count of 0.
The fourth step is to copy the shared transfer service data and certificate files to the Appliance
Now SSH to the newly deployed appliance and browse to cd /opt/vmware/vcloud-director/etc
We need to take a backup copy of the following files,
Certificates
Global.properties
Proxycertificates
Responses.properties
Enter the following command to backup each of the files to the /tmp directory,
cp certificates global.properties proxycertificates responses.properties /tmp
Then run the following command to backup the keystore file to the same /tmp location
cp /opt/vmware/vcloud-director/certificates.ks /tmp
Next we need to copy these same files over from the original vCloud instance
The following command can be used to copy the files from the original vCloud Director Cell to the newly deployed appliance. Just update the IP to reference your vCloud Cell and when prompted enter the password.
scp root@192.168.1.61:’/opt/vmware/vcloud-director/etc/certificates /opt/vmware/vcloud-director/etc/global.properties /opt/vmware/vcloud-director/etc/proxycertificates /opt/vmware/vcloud-director/etc/proxycertificates /opt/vmware/vcloud-director/etc/responses.properties’ /opt/vmware/vcloud-director/etc/
Then run the following command to copy the certificates.ks file from the original vCloud Cell,
scp root@192.168.1.61:/opt/vmware/vcloud-director/data/transfer/certificates.ks /opt/vmware/vcloud-director/
Then run the following command to reconfigure the vCloud Director Service. Make sure the keystore password is set to the password on the certificates.ks file from the original cell otherwise the command will fail.
/opt/vmware/vcloud-director/bin/configure –unattended-installation –database-type postgres –database-user vcloud –database-password P@ssw0rd –database-host 192.168.1.85 –database-port 5432 –database-name vcloud –database-ssl true –uuid –keystore /opt/vmware/vcloud-director/certificates.ks –keystore-password P@ssw0rd –primary-ip 192.168.1.84 –console-proxy-ip 192.168.1.84 –console-proxy-port-https 8443
Now it’s time to start the vCloud Director Service on the appliance,
service vmware-vcd start
You can then check the service by running service vmware-vcd status
Then open your web browser and login to the new vCloud Appliance,
https://labvcd97.stevenonofaro.local/cloud
Check through each of the settings under the Manage & Monitor tab and you will see that everything is still available and has been moved across successfully.
The last thing we need to do is remove the old cell. Under the Manage and Monitor tab click on Cloud Cells. Right click on the old Cell and click Delete.
You will now just be left with New vCloud Director 9.7 Appliance
That’s it, you have successfully migrated from vCloud Director 9.5 with an external SQL Database over to the new vCloud Director 9.7 Appliance with embedded PostgreSQL!
As always use the subscribe box above for new post notifications and follow me on twitter @steveonofaro
stevenonofaro.com 