Rok v0.7

Gateway/Indexer

Change the Nginx configuration files to point to the new installation directories for Rok Gateway and Indexer. Specifically:

root /usr/share/rok/rok_XXX;

localation /static {
   alias /usr/share/rok/rok_XXX/static;
}

where XXX is either gw or indexer.

Also, move any font files (i.e. .woff files) under /usr/share/rok/rok_XXX/static/fonts.

Fort/Indexer

Starting from this version, the Fort and Indexer Django applications support migrations. Since the respective databases already exist, we don’t have to create any tables for them, so we will fake the initial migrations. To bring the databases up to date, run the following:

fort.host# rok-fort-manage migrate --fake-initial
indexer.host# rok-indexer-manage migrate --fake-initial

Rok VASA Provider

Introduction

In Rok version 0.7, the Rok VASA Provider had a major redesign to achieve better integration with the Rok Controller.

New Storage Container UUID

In Rok v0.7 the Rok VASA Provider no longer requires hard-coded Storage Entity UUIDs defined in the RokVP settings file. Rather, RokVP dynamically discovers Rok Storage Entities and generates a UUID for each, automatically.

As a result, vSphere needs to discover the new RokVP storage entities.

Another consequence is that RokVP version 0.6 and RokVP version 0.7 use different Storage Container UUIDs. Among all Storage Entity UUIDs, the Storage Container UUID is of most importance because it is stored permanently along with the Virtual Volume metadata as well as in VM files in vSphere.

Upgrade steps

  1. Log on to vSphere using the vSphere web client
  2. Write down the current Storage Container UUID. You can get this either by inspecting the current Rok VVol datastore in vSphere or from the current Rok VASA Provider settings file. Make sure it is in the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx format and save this UUID, you will need it later.
  3. Power-off all Virtual Machines that use the Rok VVol datastore
  4. Unregister these VMs from vSphere, by right-clicking the VM and selecting “Remove from Inventory”. This will not delete any VM data.
  5. Unmount the Rok VVol datastore. This will not delete any data.
  6. Unregister the Rok VASA Provider from vSphere. Navigate to vSphere web client home page, go to the “Hosts and clusters” view, select the vCenter server, click on the “Manage” tab, then “Storage Providers”, select the Rok VASA Provider from the list and then click the red X icon on top of the list.
  7. Delete the Protocol Endpoint device from all ESXi hosts that it has been discovered over iSCSI. Navigate to vSphere web client home page, go to the “Hosts and clusters” view, select the appropriate ESXi host, click on the “Manage” tab, then “Storage”, then “Storage Adapters” and choose the “iSCSI Software Adapter” from the list of Storage Adapters. In the “Adapter Details” area, choose the “Targets” tab and remove any reference to the Rok iSCSI portal, both Dynamic and Static. Then re-scan the Software iSCSI HBA.
  8. Proceed with the Rok upgrade. Restart all Rok daemons. The rok-controllerd daemon will fail to start properly. In the logs, you should see a fatal rok_vasa.etcd_store.EtcdVersionMismatch exception.
  9. Run the migration script, see rok-vasa-manage migrate --help for more information.
  10. Restart all the Rok daemons along with the rok-controllerd daemon and restart the RokVP Gunicorn process.
  11. Register the new Rok VASA Provider to vSphere, using the rok-platform-connect-vmware script.
  12. Obtain the new Storage Container UUID, by running rok-vasa-manage storagecontainer-list.
  13. Run the vSphere migration script, see rok-vasa-manage fix-storage-container-uuid --help for more information.
  14. In the vSphere web client, navigate to the Datastores view, and click on the Rok VVol datastore, then Manage, then Files. In the datastore browser, enter each VM folder, locate the .vmx file, right-click and select Register VM....
  15. Power-on the newly registered VMs.
  16. vSphere may ask you to Answer a Question about this new VM. In this case, answer I Moved it.

Upgrade limitations

The provided migration script will help the administrator migrate from Rok 0.6 to Rok 0.7, while preserving all Virtual Volume data. After running the migration script the Rok VVol datastore will correctly list all Virtual Volumes. All VMs that were previously running off the Rok VVol datastore will power-on correctly.

However, if any Virtual Machines were located on a different vSphere datastore, say a local VMFS datastore, and if these Virtual Machines had Virtual Disks on the Rok VVol datastore, then manual intervention is required.

After the upgrade, the .vmx files on these VMs will contain a reference to a Virtual Disk path on an invalid datastore; the path will contain the old Storage Container UUID. The administrator should manually edit these .vmx files and replace the old Storage Container UUID with the new one, while preserving the following Storage Container UUID format: xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx