VMware App Volumes Datastore Migration – 2.18

This is a guide for migrating App Volumes app stacks, metadata, and entitlements to a new datastore. I’ll also cover the clean up steps to remove references to the old location(s). What will not be covered are writable volumes.

These instructions are intended for App Volumes 2.18 and may be applicable to other versions in the 2.x branch. The steps for metadata cleanup were obtained through collaboration with VMware Business Critical Support.

Update: These steps continue to work through at least App Volumes 4.9 (2212).

Requirements

  • Administrator role in vSphere vCenter.
  • Administrator role in App Volumes Manager.
  • Administrator privileges to the App Volumes Manager operating system.
  • Access to the App Volumes database server, SQL Server Management Studio, and at least DBO privileges on the App Volumes database.
  • A recent database backup in case a rollback is required.

Summary Steps

  • Use Storage Groups to duplicate existing app stacks and metadata to a new datastore.
  • Remove the Storage Group after duplication has occurred.
  • Remove the old datastore.
  • Metadata cleanup

Use Storage Groups to duplicate the existing app stacks and metadata to a new datastore

Begin by creating a new Storage Group to replicate existing App Stacks to the new datastore.
Infrastructure > Storage Groups > Create Storage Group

Storage Groups

Enter a name for the Storage Group. This is temporary and will be deleted later, so choose anything.
Select “Automatically Replicate App Stacks”.
Select “Spread” for Distribution Strategy.
Select the existing source datastore for Template Storage.
Select “Direct” for Storage Selection.
From the list of datastores, select both the old and new datastores.

New Storage Group

Confirm the change.

Confirm the New Storage Group

Switch to vCenter and verify that the App Volumes service account has duplicated the App Stacks from the source datastore to the new datastore.

Observe the Duplication Task

Switch back to App Volumes and verify that the new storage location is present within the App Stacks.

Verify the New Location in App Volumes Manager

Remove the Storage Group after duplication has occurred

Remove the temporary Storage Group.
Infrastructure > Storage Groups > Select the Storage Group > Delete Selected

Remove the Temporary Storage Group

Confirm deletion of the Storage Group

Confirm Deletion of the Storage Group

Remove the old datastore

Caution! This step is may cause a disruption if end user desktops are still mounting app stacks located on the old datastore. Before proceeding, ensure no volumes are mounted. If a maintenance window is not possible, then set the old storage location to non-mountable in App Volumes and wait until desktops restart or recycle by attrition.

Switch to vCenter and remove the old datastore. You may delete the old datastore or unpresent the LUN from storage. In any case, the datastore must not be visible to vCenter before continuing. Unmounting and detaching the datastore is not sufficient if the datastore continues to display in vCenter.

Remove the Old Datastore

Return to App Volumes and view the Storage Locations.
Infrastructure > Storages

Storage Locations

Perform a rescan.

Rescan Storage Locations

Verify that the datastore has now disappeared from App Volumes.

Observe the Removed Datastore

Select one of the App Stacks and note that the old location is still present.

App Stacks

Perform a rescan.
You can select either Wait for Completion or Perform in the Background. If you select Perform in the Background, you will need to reload the page when the rescan completes.

Rescan App Stacks

Note that the App Stack still has the old location listed, but now lists the location as unavailable.

App Stacks

Metadata cleanup

You should now connect to the SQL Database using SQL Server Management Studio or an equivalent tool. You will need the location ID of the datastore that is being removed in order to clean up the stale reference.

Connect to the App Volumes database and expand the tables list. Look for a table named “dbo.storage_locations”. Right-click this table and select “Edit Top 200 Rows”

SSMS

Note the ID number next to the datastore that has been removed.
In the example here, I am removing datastore NETAPP_SSD_A-700_LUN2_APPVOL2 with ID 7.
Make a note of the ID for your situation.

Storage Location ID

You now need to connect to the RVC console on one of the App Volumes Managers.
(See Omnissa KB 2125212 for more information on the App Volumes RVC console)

Open an administrative command prompt and navigate to the App Volumes Manager program directory.
By default, this is C:\Program Files (x86)\CloudVolumes\Manager

Start the RVC console using:
svmanager_run script\rails console

RVC

Remove all App Stacks references to the datastore location ID previously noted. Use the ID number from your database.

Output a list of object references with the following command. Replace # with the ID number you noted.
SnapvolFile.where(storage_location_id: #).each

Caution! The following command is destructive and will permanently remove information from the database. Ensure that adequate database backups exist.

 

Perform cleanup with the following command. Replace # with the ID number you noted.
SnapvolFile.where(storage_location_id: #).destroy_all

RVC

Return to the SQL server and delete the row containing the storage location that is being removed.

SSMS

Return to the App Volumes Manager web interface. Perform a rescan on the App Stacks.
You should now see the old database references removed from the App Stacks.

App Stacks

Restart services on any replica App Volumes Managers.