Velostrata v2.1 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 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. Virtual Machine disks in Independent mode (persistent and non-persistent) and Physical RDM mode are not supported.

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.

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.

  • For RHEL/CentOS 6.x, 7.x, download and install the Velostrata RPM from: http://tiny.cc/velos-v2-rhel6
  • For SUSE 11, download and install the Velostrata RPM from: http://tiny.cc/velos-v2-suse11
  • AWS instance type - c4.8xlarge - 10G network is not supported for a RedHat workload.
  • AWS instance type - g2.2xlarge - is not supported for a RedHat workload.

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

VPN Connection Bandwidth

A minimum of 20 Mbit/sec symmetric or equivalent VPN connection bandwidth is required for acceptable access times when moving a VM to the cloud. As a general guideline, 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 40 VMDKs per ESX host, for virtual machines that run in the cloud (whether active or stopped). 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.
  • Migration to cloud is not supported for a Virtual Machine with more than 20 disks.
  • 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 VM size instances A0-A3 to fail booting in cloud in some locations. Workaround: use D or DS VM size instance instead.

Fixed Issues

Build 2.1.0.8563

#2210: A Velostrata managed workload that was started via Azure Resource Manager would fail to boot but its state will remain running in VM portlet.

#2114: In rare cases, when the vCenter or ESX host is stressed, a Workload running in the cloud may be unable to perform a write-back of changes back to on premises storage.

Build 2.0.0.8025

#2650: Due to disruptions Velostrata Exporter may get into an infinite loop

Build 2.0.0.7989

#2069: Error massage "java NullPointerException in vSphere UI" may appear when trying "Reconfigure Cloud Instance" for a Workload while it is in a Move back state.

Build 1.3.0.6461

#536: The Create Cloud Extension wizard allows an empty Cloud Extension name field. The task will start but will faillater. A non-empty name is mandatory.

#668, #1057: When multiple run-in-cloud tasks are in progress, canceling a single task may, on some occasions, cause another task to cancel as well.

#1214: Newly created Cloud Extension information may appear in the summary tab portlet for a virtual datacenter after a 1-minute delay.

#1396: The Velostrata vCenter Web Client Plug-in registration page on the Velostrata Manager Virtual Appliance for vSphere does not accept a FQDN of the vCenter server.

Build 1.0.0.5421

This update adds support for CentOS 6 (64 bit) as well as non-LVM configurations for RHEL. The RHEL and SUSE RPMs have been updated and should be reinstalled to replace older version deployments.

#1735 - Updated the Velostrata Windows driver signing certificate used during Run-in-Cloud.

#1581, #1583, #1696:  Improvements added to SUSE 11 RPM to allow improved service load handling.

#1589, #1643, #1682, #1710: Improvements added to RHEL 6 RPM and offline servicing to handle further boot variations such as non-LVM setup, multiple GRUB entries, boot without a separate boot partition.

Build 1.0.0.5184

* ENI Support - added an option to specify a reserved Elastic Network Interface (ENI) in the Run-in-Cloud wizard. To use this capability, select Static option in Private IP field, and specify the ENI ID string (eni-xxxx) instead of an IP address. Running a VM in the cloud with a specified ENI allows for a reserved MAC address to be used, which certain application licenses may require. An ENI also allows a reserved Public IP (EIP) association to be preserved across VM movement, for a consistent public service address configuration.

 Note: when specifying an ENI, the ENI settings for subnet and security group and EIP assignment will apply and override any respective prior selection in the wizard.

* Removed Public IP checkbox option in the Run-in-Cloud wizard due to usability issues. To gain Internet access when a VM is running in the cloud, use one of the following options:

   (1) When running in a subnet where the default route 0.0.0.0/0 is associated with an Amazon Internet Gateway (IGW), you may reserve and assign an Elastic IP (EIP) using the AWS console.

   (2) When running in a subnet where a NAT Gateway is configured, Internet access will be provided by the NAT Gateway.

   (3) When running in a subnet where the default route 0.0.0.0/0 is associated with an Amazon VPN Gateway (VGW), Internet access will be routed according to the VPN Gateway static routes or BGP published routes.

Build 1.0.0.5058

#1380 - Rare race condition on read request.

#1495 - Write back checkpoint aborted due to the race between management RPC and storage connection teardown.

#1598 - Velostrata Manager virtual appliance does not reconnect to the vCenter after certain vCenter outage scenarios.

#1618 - Write back does not resume after certain vCenter connectivity loss scenarios.

#1633 - Inflated logs on Velostrata Edge due to debug level configuration.

Build 1.0.0.5024

#1593: AWS service region addition caused failure to create a new Cloud Extension.

#1623: Velostrata Manager virtual appliance service disruption due to the lack of free disk space.

Build 1.0.0.4054

#1395: The Finish button in the Reconfigure Virtual Machine wizard remains disabled in Internet Explorer and Firefox. Note: 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.

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

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 a large number of pending writes may take a while. Do not use the Force option as this will result in the loss of the uncommitted writes.

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

Workaround:  Log out from the vSphere web client and re-login.

#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: Retry the operation.

#1667: vCenter reboot causes Velostrata tasks in vCenter to disappear from UI.

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

#2124: In rare cases when moving a workload back to premises, the Velostrata task might be shown as failed although it finished successfully. This is due to vm snapshot consolidation task taking too long to finish.

Workaround: It is safe to ignore this task massage.

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

Workaround: Pause the storage migration first, and then start the run-on-premises task.

#1951: When moving a Workload to the cloud while the ESXi host is running, it is put into maintenance mode meaning that a rollback will be performed but will get stuck.

Workaround: Manually cancel the task and re-run the Run in cloud operation for the workload after it was moved to another ESXi host.

#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: Contact support.

#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.

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

Workaround: Reboot the Workload.

#2136: Post Velostrata version upgrade - in some cases Windows workload may enter a boot loop state

Workaround: Contact support.

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

Workaround: Retry the operation.

#2551: Workload whose disks were shrunken is unable to boot in cloud.

Workaround: Contact support.