Velostrata v2.6 Release Notes
2.6.5 (build 13860)
Azure: Windows Hybrid Use Benefit (HUB)
You can now save costs by using your on-premises license when migrating a windows server to Azure with Velostrata.
Offline Migration – Windows Server 2008 (non-R2)
Offline migration of Windows Server 2008 (non-R2) was tested successfully and works since Velostrata version 2.6. Further migration optimization added in version 2.6.5.
Linux: configuration adaptation of direct mounts for cloud
Some device mount configurations (e.g. /dev/sda) are not identified correctly when migrating to AWS. Velostrata Linux RPM now automatically adapts physical source name to UUID to overcome this.
Linux: configuration adaptation of LVM for cloud
LVM (Logical Volume Management) discovery filters in some Linux distributions does not work correctly with cloud disk naming. Velostrata RPM now adapts LVM filters to overcome this without the need for manual intervention.
Velostrata Powershell module is now signed with Velostrata certificate to enable security measures in Powershell execution policy.
Wannacrypt vulnerability (MS17-010) fix
Solution for Windows vulnerability MS17-010, also known as Wannacrypt, that was reported by Microsoft here: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx.
This version includes installation of Windows hotfix KB402216, and blocking of non-required ports including of relevant SMB ports: 445,139.
Offline Migration Solution for Windows 2003, RHEL5 and More
Migrate workloads with operating systems that are not yet supported by Velostrata’s streaming technology. In the offline migration process, the VM storage is migrated to the cloud first and started in the cloud only after the storage migration and detach action is completed. Preparation procedures are required on-premises before migration is started. Procedures are provided for Windows 2003 and RHEL 5. Contact Velostrata Support for other operating systems or versions. For further details, see Using Offline Migration.
BETA: Added Support for Physical Servers in Source
It is now possible to migrate physical servers, running in cloud in cached mode within minutes, while migrating storage to the cloud. For further details, see Migrating Physical Servers.
Tenancy Type (Dedicated Instances) and Disk Encryption
For AWS, an option was added to select a “dedicated instances” tenancy type for a cloud extension and its related workloads. In this mode, the AWS hardware is shared only with instances of the same account. When creating the native EBS drives, as part of the prepare to detach operation, encrypted EBS drives are used if the “dedicated instances” tenancy type was selected. For further details, see Adding a Cloud Extension.
Automation Runbook Changes
The following invoke commands were added:
- Test Clone.
- RunOnPrem Performs either move-back or delete clone, based on the VM running mode.
- Start Migration Changed from previous version. Now there is a single command to manage the following separate operations: move VM to cloud, storage migration and prepare to detach.
- Offline migration . For further details, see Using Offline Migration.
A custom tagging option has been added as optional automation runbook column(s). Currently applicable only to AWS instances. For further details, see Creating the Rubbook.
Added Support for VMware vSphere Version 6.5
Added Support for VMware vCenter Server in Linked Mode (Versions 5.5, 6.0, 6.5).
Note: You must install a Velostrata system per vCenter server.
Compatibility and Installation
ESXi, vCenter Server, and vSphere Web Client Compatibility
This Velostrata release is compatible with vSphere 5.5 U1 or higher, vSphere 6.0 U1 or higher; vCenter 6.5 is supported with ESXi of versions 5.5, 6.0.
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. As a minimum, version 5.5 or higher of vCenter is required even in cases where the 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 be updated to the latest version. Use Flash player version 188.8.131.52 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. A conversion procedure may be available contact Velostrata Support.
Velostrata makes use of Virtual Machine snapshots. Virtual Machine disks in Dependent mode (default) and Virtual RDM mode are supported with full functionality.
Virtual Machine disks in Independent mode (persistent and non-persistent) and Physical RDM mode are supported with limited functionality contact Velostrata Support for details if used.
IDE virtual disks are currently not supported. Change the virtual disk type to SCSI to enable move to cloud.
Physical Server Support (Beta)
Migrating a physical server to cloud is done by booting a Velostrata Connector ISO image into RAM from a virtual or physical DVDROM/CDROM device. The Velostrata connector maps the local storage and creates a Stub VMware VM as a management object for Velostrata cloud migration operations. From this point on, the migration is done in similar way to the migration of other VMs, only in Write Isolation mode.
Note: The Stub VM created in the process is intended for Velostrata management operations only, and not set up for local execution on vSphere. It is set up with no network interface, and a minimal CPU/RAM setting.
- Disk types supported include SAS, SATA, SSD, virtual disks presented by hardware controller, and SAN volumes mounted on physical HBAs. PATA/IDE disks are not supported.
- Minimum 4GB RAM.
- Physical DVDROM/CDROM or virtual CDROM to boot the Velostrata Connector ISO from.
Follow user guide instructions for the physical migration process. For further details, see Migrating Physical Servers.
Guest Operating System Compatibility
Supported Windows versions:
- Windows Server 2008 R2 SP1 or higher.
- Windows Server 2012/Windows Server 2012 R2.
- Windows 2016 Beta support. Currently available for AWS only.
- Windows Server 2003 Supported with offline migration. Requires a preparation procedure on-premises, prior to migration. For further details, see Using Offline Migration.
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 BETA level support.
- RHEL 5.1 or higher 64-bit Supported with offline migration. For further details see: Using Offline Migration
- RHEL 5.11 and higher supported also with 32-bit for AWS t2 instances using offline migration
You 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 run-in-cloud.
Note: Block device naming considerations differ across target cloud provider and depend on underlying virtualization platforms. Velostrata recommends you 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 automatically checks for direct device mapping in typical configuration files and a warning appears during installation if any is found. A script is provided in the RPM to change such configurations to use GUIDs as device names.
Only MBR disks are supported for Guest OS boot disks. Both MBR and GPT disks are supported for data disks. If you have machines with GPT boot disks, contact Velostrata Support for possible conversion options.
#4266: run-in-cloud or migratoin operation may fail for windowws 2016 workload when symantec endpoint protection(SEP) is installed. This may happen also in case SEP appears to be disabled.
Workaround: disable SEP using the following powershell command: Disable-NetAdapterBinding -IncludeHidden -AllBindings -Name "*" -ComponentID "symc_teefer2"
Cloud Instance Type Compatibility
The following AWS instance types may experience missing driver issues. 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 Instance type 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.
#3779: Workloads running Windows OS may fail to boot in Azure using A-series VM sizes.
Workaround: Use Av2-series VM sizes
#4432: Workloads running Windows 2008R2 fail to boot in Azure using DSv2-series VM sizes.
Workaround: Use alternative VM sizes (e.g. Av2-series and D-series)
VPN/DirectConnect/ExpressRoute Connection Bandwidth
The minimum link bandwidth recommended would be the larger of:
- Link bandwidth of 20 Mbit/sec, symmetric,
- Upload bandwidth to cloud calculated as total number of VMs migrating concurrently, multiplied by 0.5-1 Mbit/sec per VM.
This is required for acceptable access times when moving VMs to the cloud in streaming mode.
For example, Velostrata recommends a minimum of 50-100 Mbit/sec for production use of up to 100 VMs running in the cloud.
- VMware virtual disk consolidation warning - 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.
- Typical storage throughput per virtual disk - Due to vSphere Storage API limitations, throughput achieved on-premises per VMDK is observed to be limited to about 20-30Mbytes/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.
- Maximum concurrent read sessions per ESX host - 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 or RDMs 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.
Free space on source datastore - Write back activity for a VM running in the cloud is temporarily put on hold when the backing vSphere Datastore’s free capacity is lower than 10%, and a vCenter Alarm is raised to indicate of the issue. 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.
#3647 - The "collect console log" action button in the Velostrata portlet on the VM Summary page does not work when running the vCenter Web Client on Google Chrome browser, in “Incognito” mode.
Workaround: Work in Chrome normal browsing mode.
2.6.5 (Build 13860)
Following introduction of a new VM size, "Prepare to detach" action in Azure may fail for virtual machines that have only one or two disks. Virtual machines with three disks or more are not affected. Fixed
2.6.5 (Build 13680)
|In some rare cases the Storage Grid failed.
||Issue fixed. Additionally, automatic healing was added to the storage grid component.
|4378||Some core dumps taken for troubleshooting purposes were too large and hard to manage.
||Fixed. Removed unneeded data|
|4338||When selecting Tenancy Type = “Default (inherited from VPC settings)”, and the VPCsettings are set to use Dedicated Instances, the Cloud Extension creation fails.
||Velostrata virtual appliance fails to deploy in VMware environment when vSphere 6.5b issued due to VMware bug in reading VcIP parameter.
||Fixed. Removed the read of VcIP (no longer shown in the Velostrata portal)
|4247||Exporter experiences network disconnections.
|4237||Windows VM preparation to run in cloud failed in some cases
|4146||Windows 2008 and higher may encounter Microsoft time sync issues that results in network inaccessibility due to DHCP lease time.
|4072||In some rare scenario CloudExtension log files were not properly rotated, causing system operation disruptions.
Azure - when checking instance health for VMs that fail to boot, excessive calls to Azure APIs may occur
Windows NLB (Network Load Balancing) service installed on a network interface in Windows server fails on boot in cloud.
Fixed by removing the service before running in cloud. Windows NLB is not supported on Azure or AWS.
/etc/hosts file when running in streaming mode in cloud is regenerated on every boot, deleting any user settings.
Fixed. The primary IP for the hostname entry is updated in-place while preserving other content.
VM running CentOS/RHEL 6.x which has NICs attached to specific MAC address were not reachable after detach.
#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.
# 3775: When performing a detach after a cancel detach operation, the action may fail.
Workaround: Retry the operation.
#3682: In the event of certain system failures, Velostrata components disconnect from vCenter. In this case, an event may not be sent, resulting in the alarm either not being set properly or not being cleared properly.
Workaround: Clear the alarm manually in vCenter.
#3412: In some cases, creating a Cloud Extension fails with the following message: "Failed to Create Cloud Extension: Your previous request to create the named bucket succeeded and you already own it…."
Workaround: Use the Repair CE Velostrata operation.
#3320: For workloads with Windows machine using a retail license, when returning from the cloud, the license is not present.
Workaround: Reinstall the license.
#3281: Export OVA is an available option when VM in cloud is running in cache mode, however, this operation results in a corrupted OVA.
Workaround: Only create OVA after the detach.
#3142: In rare cases, when a cloud component instance is created and system fails before it is tagged, the instance will remain untagged. This will not allow full clean-up or repair of the CE.
Workaround: Manually tag the instance, and then run "Repair"
#2596: In Azure, in some cases when canceling the detach operation in the middle of the operation - after the instance is terminated, the VM rolls back on-prem.
Workaround: Instead of cancelling the detach task in process, wait for the task to complete and then run the “Cancel Detach” action.
#3681: Workloads running RHEL7.2 fail in AWS instance type g2.8xlarge.
Workaround: Use a different instance type.
#4012: Storage policy and security group cannot be changed in Spot market bid mode.
#3988: AWS: when performing detach or reconfigure actions for a VM in dedicated instance tenancy type, and choosing an instance type that is not supported by AWS for dedicated instances, the instance will not be able to run in the cloud.
Workaround: Change the cloud instance type to one that is supported in dedicated instances mode.
#3265: Too many parallel stop/start VM in cloud requests (API, PowerShell or vCenter Web Client Plugin) may cause operation to time out. Please note this limitation does not apply for the Automation Runbook as requestes are sequencial
Workaround: limit concurrent start/stop requests to 10.
#3908: In some cases, a test clone operation would fail when the system cannot create snapshot in quiesce mode through vCenter.
Workaround: Ensure that VMware Tools are activated on the VM guest to allow quiescing.