Velostrata v2.3 Release Notes

Compatibility and Installation

ESXi, vCenter Server, and vSphere Web Client Version Compatibility

This Velostrata release is compatible with vSphere 5.5 U1 or higher and vSphere 6.0 U1 or higher

Web Browser Compatibility

The latest versions of the following web browsers are known to be compatible with the Velostrata vCenter Web Client plugin: Chrome, Internet Explorer, Firefox, Safari.

The vCenter Web Client leverages the Adobe Flash extension in your browser. Velostrata recommends that the Flash plug-in for your browser is updated to the latest version. Use Flash player version or later.

To check your current Flash player version, go to:

Virtual Machine Compatibility

Only virtual machines configured with BIOS virtual firmware are supported. UEFI virtual firmware isnot supported.

Velostrata makes use of Virtual Machine snapshots. Virtual Machine disks in Dependent mode (default) and Virtual RDM mode are supported. Virtual Machine disks in Independent mode (persistent and non-persistent) and Physical RDM mode arenotsupported.

IDE virtual disks are currently not supported. Change the virtual disk type to SCSI to enable move to cloud.

Guest Operating System Compatibility

Supported Windows versions: Windows Server 2008 R2 SP1 or higher, Windows Server 2012 and Windows Server 2012 R2. No pre-installation is required for Windows Virtual Machines.

Supported Linux distributions and versions: RHEL 6.x, RHEL 7.x, CentOS 6.x, CentOS 7.x, SUSE Linux Enterprise Server 11 SP2 or higher.

Only MBR disks are supported for Guest OS boot disks. Both MBR and GPT disks are supported for data disks.

You will need to install the pre-requisite Velostrata prep RPM package and its dependencies on the virtual machine you intend to run in cloud. The Velostrata package can remain installed when the virtual machine is running on-premises to allow for a future impromptu run-in-cloud.

Cloud Instance Type Compatibility

The following AWS instance types may experience missing driver issues. Please refer to the AWS driver lists for specific kernel and driver information.

For C4 types, see:

For G2 and P2 types, see:

For X1 types, see:

Known Compatibility Issues

  • c4.8xlarge - Verified to work with CentOS 6.8, 7.2, RHEL 7.2, SUSE 11 SP4 and Windows Server 2008 R2 SP1, Windows Server 2012 R2. Not supported with RHEL 6.x.
  • g2.2xlarge - Verified to work with CentOS 6.8, 7.2, SUSE 11 SP4 and Windows Server 2008 R2 SP1, Windows Server 2012 R2. Not supported with RHEL 6.x, 7.2.
  • x1.32xlarge - Verified to work with CentOS 6.8 and RHEL 7.2, SUSE Linux Enterprise for SAP Applications 11 SP4. Not supported with RHEL 6.x, CentOS 7.2, SUSE 11 and Windows Server.

VPN Connection Bandwidth

A minimum of 20 Mbit/sec symmetric or equivalent VPN connection bandwidth and 0.5-1 Mbit/sec upload BW to cloud is required for acceptable access times when moving a VM to the cloud.

For example,  Velostrata recommends a minimum of 50-100 Mbit/sec for production use of up to 100 VMs running in the cloud.

Known Limitations

  • When write-back consistency checkpoints are persisted in the vSphere Datastore on-premises, a snapshot rotation and virtual disk consolidation is performed. During consolidation, the virtual machine will have an event showing that its disks require consolidation. This status is temporary and will automatically get resolved when consolidation triggered by Velostrata has completed. A similar behavior occurs when moving a virtual machine to run back on premises.
  • Due to vSphere Storage API limitations, throughput achieved on-premises per VMDK is observed to be limited to about 20Mbytes/sec. When workloads are highly concentrated into a single virtual disk, the initial performance seen in the cloud may be limited due to an increase in storage access latency back on-premises. This situation typically resolves itself within minutes, as soon as an active working set is established in the Velostrata cache, in the cloud.
  • Due to vSphere Storage API limitations, the number of storage access sessions per ESX host is constrained. Velostrata enforces a limit of up to 60 VMDKs per ESX host, for virtual machines that run in the cloud (active). Multiple ESX hosts may be used. Given that these virtual machines are not actually executing on the ESX hosts, these hosts can be of minimal specs.
  • A system event is not yet implemented for write back that is put on-hold. The write back for a VM running in the cloud is put on hold when the backing vSphere Datastore’s free capacity is lower that 10%. Write back will resume automatically as space is freed up on the datastore. Workaround: Monitor the Uncommitted Writes counter and correlate it to low-disk space events from the vSphere datastore. When write back is put on-hold, the Uncommitted Writes graph indicates a growing count for longer periods.
  • Workloads with VMDK size larger than 2TB will fail to boot in cloud. Workaround: Use VMDKs smaller than 2TB, otherwise contact support to obtain hotfix.
  • Inconsistencies between Azure locations may result A-type VM size instances A0-A3 to fail booting in cloud in some locations. Workaround: use D, F or DS VM size instance instead.

Fixed Issues


#2023, #2071: Velostrata Cloud Extension Portlet might take time to update.

#2054: When attempting to move a workload that is in a "Migrating storage" state back to on premises, the error message - "a previous task is already in progress" appears indicating that the move failed.

#1773, #1806: WAN disruption may cause RHEL\SUSE workloads not to complete a boot sequence in the cloud.

#2490: After performing a Detach operation - Workload is unable to complete its boot.

Known Issues

#1257: When Velostrata Prep RPM is installed on a SUSE Linux Enterprise Server 11, the VM obtains a DHCP IP address in addition to an existing static IP configuration. This issue occurs when the VM is started on-premises in a subnet that is enabled with DHCP services.

Workaround: The issue does not occur when the subnet has no DHCP services. There is no connectivity impact for communications with the original static IP address.

#1027: In some cases, when a VM is moved to run-in-cloud while a 3rd party VM-level backup solution holds a temporary snapshot, the Velostrata periodic write-back operations will not complete even after the backup solution deletes the temporary snapshot. The uncommitted writes counter on the VM will show an increasing size and no consistency checkpoint will be created on-premises.

Workaround: Select the Run On-Premises action for the VM and wait for the task to complete, which will commit all pending writes. Then select the Run-in-Cloud action again. Note that committing many pending writes may take a while. Do not use the Force option as this will result in the loss of the uncommitted writes.

#1745: After registering the Velostrata plug-in, creating a Cloud Extension might fail.

Workaround: Un-register the Velostrata plug-in and restart the vSphere web client service, then re-register the plug-in. Contact support if issue persists.

#1744: In rare cases, creating a Cloud Extension in Microsoft Azure fails due to the Azure service reporting it is busy.

Workaround: If the Cloud Extension appears in “impaired” state, retry using the “Repair Cloud Extension” operation. If no Cloud Extension entry is shown, retry the create operation.

#1667: vCenter reboot causes Velostrata tasks in vCenter to disappear from UI. This is a vCenter limitation.

Workaround: Use the Velostrata PowerShell module to monitor Velostrata managed VMs or Cloud Extensions tasks that are currently running.

#1951: With an ESXi host in maintenance mode, if a VM is moved to cloud, the operation will fail but will get stuck in rollback phase.

Workaround: Manually cancel the Run-in-Cloud task, migrate the VM to another ESXi host in the cluster and retry the Run-in-cloud operation.

#1917: A Run-in-cloud operation fails with the error - "Failed to create virtual machine snapshot. The attempted operation cannot be performed in the current state (Powered off)".

Workaround: The VMware VM snapshot file may be pointing to a non-existent snapshot. Contact support for assistance in correcting the issue.

#1808: After running a Workload back on premises - Workload VMDK's are locked. In certain cases, this is due to network disruptions between the Velostrata management appliance and the ESXi host on which the workload is running.

Workaround: The issue will resolve itself after 1-2 hours.

#2551: Workload whose disks were shrunk using VMware-Converter is unable to boot in cloud.

Workaround: VMware-Converter may have replaced the MBR to a non-supported version. Contact support for assistance in correcting the issue.

#2736: During Detach, operation might fail with the following error message "Operation was canceled"

Workaround:Retry the Detach operation.