Velostrata v2.4 Release Notes

What’s New in v2.4

Velostrata version 2.4 is adding Azure Marketplace support for integrated pay-as-you-go billing. 

See: http://velostrata.com/AzureMarketplace for more information.

Contacting Support

All Velostrata BYOL and Marketplace subscription include support. For options to contact support see: http://velostrata.com/support

When reaching out to support, please include your Velostrata Subscription ID (for BYOL customers), your AWS 12-digit account number for AWS Marketplace users or your Azure Subscription ID for Azure Marketplace customers.

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. In certain configurations, ESXi version 5.0 and 5.1 may be used, please contact support for details.

vCenter is a required component in a deployment. At minimum, version 5.5 or higher of vCenter is required even in cases where ESXi host version is lower.

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 19.0.0.245 or later.

To check your current Flash player version, go to: http://www.adobe.com/software/flash/about/.

Virtual Machine Compatibility

Only virtual machines configured with BIOS virtual firmware are supported. UEFI virtual firmware is not supported.

Velostrata makes use of Virtual Machine snapshots. Virtual Machine disks in Dependent mode (default) and Virtual RDM mode are supported at full functionality.

Virtual Machine disks in Independent mode (persistent and non-persistent) and Physical RDM mode are supported at limited functionality  contact support for details if used.

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

Guest Operating System Compatibility

Windows

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.

Linux

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. SUSE Linux Enterprise Server 12 is currently in BETA level support.

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.

Note: block device naming considerations differ across target cloud provider and depend on underlying virtualization platforms. Velostrata recommends to use either LVM or GUID based device names in configuration files such as those used by the boot loader, file system and mount tables. The Velostrata RPM will automatically check for direct device mapping in typical configuration files and indicate in a warning during installation if any found. A script is provided in the RPM to change such configurations to use GUIDs as device names.

General

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

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:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/c4-instances.html

For G2 and P2 types, see: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cluster_computing.html

For X1 types, see:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/x1-instances.html

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.

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.

#2811: Azure - In rare cases, a "Run in Cloud" operation might fail.

Workaround: Retry the operation.

#3466: Velostrata Manager fails to start an Azure VM that is stopped externally (not using the Velostrata manager UI, PowerShell Module or API), if it is left in Stopped but not Deallocated state.

Workaround: Using the Azure Portal, Stop and Deallocate the VM, then Start using the Velostrata Manager.

#3472: Cancel detach might fail due to network disruptions.

Workaround: Retry the operation.

#3510: Azure Marketplace error - "409, Code: ResourcePurchaseCanceling" - a "Cancel Detach" operation might fail if initiated less than 15 minutes following a previous detach operation.

Workaround:Contact Support.

#3512: Azure Marketplace error - "500, Code: InternalBillingError when trying to purchase too close to previous cancel" - a "Cancel Detach" operation might fail if initiated less than 15 minutes following a previous detach operation.

Workaround:Wait for 15 minutes and Retry the operation.