Upgrading App Volumes Manager Servers
Upgrading App Volumes Manager Servers
Upgrade Options for App Volumes
There are basically two strategies for upgrading during a scheduled maintenance window:
- Full change window – In an ideal world, we recommend planning a full change window (outage), meaning you would take the App Volumes Manager servers offline and make sure no users are connected to the environment. You could then update all servers before bringing them back online. This is the safest method because it ensures that no changes are made to the environment during the upgrade process. That being said, we recognize this is not always possible.
- Rolling upgrade – A rolling upgrade of the App Volumes Manager servers can alternatively be performed during the change window. In this model, you update the App Volumes Manager component on one server at a time, rolling through the upgrade process until all servers are upgraded. Because only one server is taken offline at a time, the App Volumes Manager service remains available, and end users will still have AppStacks and writable volumes attached to their virtual machines during the upgrade process.
Prerequisites for Server Upgrades
- If you plan to perform a rolling upgrade, take the necessary precautions to ensure that administrators will not log in to the App Volumes Manager web-based UI and make any configuration or assignment changes.
For example, send email notifying the administrators of the change window you plan to use.
- If you plan to use a full change window for the upgrade, and take all App Volumes Manager servers offline at the same time, be sure to notify both administrators and end users that they will not be allowed to connect to the environment during the change window.
Note: New logins would be affected during the upgrade process. If you take all servers offline at the same time, or if you have only one server (not recommended for production environments), the App Volumes Manager service will be unavailable during the upgrade. AppStacks and writable volumes would not be attached if end users logged in to their virtual machines during the upgrade.
- Back up the App Volumes SQL database.
Workflow to Upgrade App Volumes Manager Server
- Perform the tasks outlined in the Prerequisites section, in this guide.
- If you have multiple App Volumes servers behind a load balancer, remove or turn off authentication to the first App Volumes Manager server you plan to upgrade.
- Use vCenter Server to take a VM snapshot of the App Volumes Manager server.
Be sure to choose the Snapshot the virtual machine's memory option.
- Back up the App Volumes Manager server certificate and the
nginx.conffile, located in:
Drive\Cloud Volumes\nginx\confNote: App Volumes Manager uses TLS/SSL to communicate with Active Directory, machine managers, and App Volumes Agents. It is important to replace the self-signed certificates with CA-signed certificates, especially for AppVolumes implementations in a production environment. For more information, see Using SSL Certificates with App Volumes Manager, in the VMware App Volumes Administration Guide.
- On the first App Volumes Manager server to be upgraded, stop the App Volumes Manager service:
From the Start menu, go to Administrative Tools > Services and stop the App Volumes Manager service.
- Take note of the current time on the App Volumes Manager server.
You will reference this time stamp in a later step when reviewing the App Volumes Manager log files.
- Copy the server logs from
Drive\Program Files (86)\CloudVolumes\Manager\Logto a remote file share.
These log files will not exist after the upgrade, and you might need them for reference.
- Log in to the App Volumes Manager server as an administrator and run the App Volumes installer.
- Do not overwrite the database. Follow all prompts and connect using ODBC Native Client credentials.
- When you choose network ports during App Volumes Manager installation, select the Allow Connections Over HTTP (insecure) option.
This is optional but recommended when performing an upgrade. If you have any issues with your certificates or communications between components, you can try an alternate route (HTTP), which streamlines troubleshooting.
Note: Be sure to disable this option once the upgrade is complete and functionality has been verified.
- When installation is complete, navigate to the
svmanager_setup.logfile in the App Volumes Manager
Logfolder and verify that the upgrade was successful.
C:\Program Files (x86)\Cloud Volumes\Manager\LogIn the
svmanager_setup.logfile, which contains a list of migration steps performed, verify that the last entry is AddTimeStampsToMachineManager. If you see this entry, and there are no errors before that line, you can safely assume the upgrade worked successfully.
- If you use a load balancer and removed or disabled authentication to the App Volumes Manager server in step 2, add the server back or turn on authentication.
Repeat this procedure on the remaining App Volumes Manager servers.
Verifying a Successful Upgrade of App Volumes Manager Servers
To verify the upgrade, you examine some log files.
1. Use the App Volumes Manager Dashboard to View System Messages
Once the upgrade is complete on all servers, login to the App Volumes Manager dashboard, select the System Messages tab, and make sure there are no errors in the logs.
2. Use the Browser to View Logs
https://<avm_FQDN>/log and find the timestamp you noted in the previous exercise. Look for any errors. If errors are found, troubleshoot and open a ticket with VMware Global Support Services as needed.