Velostrata v3.1 Release Notes
Cloud-to-Cloud Migration: AWS to GCP
Velostrata V3.1 introduces cloud-to-cloud migration support. In addition to Velostrata’s support of AWS and Azure and GCP, you can now migrate VMs in streaming mode from the AWS cloud to GCP.
This release introduces a new orchestration engine that runs on the management appliance to manage and run large-scale migrations from the source cloud to the destination cloud. The Cloud-to-Cloud Runbook includes a new UI and a PowerShell module.
V3.1 now supports GCP in GA. This includes support for Run in Cloud, Storage Migration, Offline Migration, Reconfigure CE and VM, Right Sizing, DNS, and IP Aliases. The system is fully tested for large-scale migrations to GCP as the target (either from on-prem or from the AWS cloud).
Ubuntu 17.10 and Windows Server 1709 Support
This release includes streaming migration support for Ubuntu 17.10 and Windows server 1709.
New System UI
Velostrata V3.1 introduces a new system UI for easier management of the system.
Cloud Extension Custom Tags
A cloud extension can now have multiple custom tags added to every instance created in the cloud extension. This allows for easier management of resources migrated to the cloud.
Compatibility and Installation
ESXi, vCenter Server, and vSphere Web Client Compatibility
This Velostrata release is compatible with the following VMware versions:
- vCenter: 5.5U1, 6.0U1, 6.5, 6.5U1.
Note: vCenter is a required component in a deployment.
- ESXi: 5.5U1, 6.0 U1.
Note: 5.0 and 5.1 may be used in certain configurations; contact support for details.
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, and 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 184.108.40.206 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 for possible conversion options.
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
Migrating a physical server to cloud is done by booting a Velostrata Connector ISO image into the server’s 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 a 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 is 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.
For further details and for instructions for the physical migration process, see Migrating Physical Servers in the User Guide.
Guest Operating System Compatibility
Supported Windows Versions:
- Windows Server 2008 R2 SP1 or higher
- Windows Server 2012/Windows Server 2012 R2
- Windows 2016
- Windows server 1709
Supported Windows Versions with Offline Migration
- Windows Server 2003, Windows Server 2003R2, Windows Server 2008
For further details, see Using Offline Migration in the User Guide.
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 SP2 or higher
- Ubuntu 14.04.x, 16.04.x, 17.10.x
Supported Linux Versions in Offline Migration
- Ubuntu 12.x
- RHEL 5.1 or higher 64-bit RHEL 5.11 and higher supported also with 32-bit
For further details, see Using Offline Migration in the User Guide.
Note: Block device naming considerations differ across target cloud providers and depend on the underlying virtualization platforms. Use of either LVM or GUID-based device names in configuration files is recommended. The Velostrata RPM automatically checks for direct device mapping in the typical configuration files (/etc/fstab, and GRUB) and replaces the physical source (e.g., /dev/sda/) with a GUID.
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 and migration operations may fail for Windows Server 2016 workload when Symantec Endpoint Protection (SEP) is installed. This may also happen when SEP appears to be disabled.
- Modify workload network interface bindings to remove SEP option.
- Download Microsoft Network VSP Bind (nvspbind) - download link.
- Install Microsoft_Nvspbind_package.EXE into c:\temp.
- Open the command prompt as an Administrator and run the following: nvspbind.exe /d * symc_teefer2.
Known Instance Type Compatibility Issues
The following AWS instance types may experience host missing driver issues. Refer to the AWS driver lists for specific kernel and driver information.
- 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
Specific AWS instances
- 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 or Av3 series VM sizes.
The minimum link bandwidth between on-premises or source cloud and the Cloud Extension nodes is recommended to 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 appropriate 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 persist in the vSphere Datastore on-premises, a snapshot rotation and virtual disk consolidation is performed. During consolidation, a virtual machine event indicates that its disks require consolidation. This status is temporary and is automatically 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 the issue. Write back automatically resumes 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.
#2596: In Azure, in some cases when canceling the detach operation in the middle of the operation – after the instance is terminated, the VM rolled back on-prem.
#4967: Run In Cloud failed with an error when the VM name contained characters not supported by the target cloud provider.
#4961: When moving a machine from GCP to on-prem or after the clean-up operation, the reserved address created by Velostrata for the machine would be released within an hour.
#4915: Following a successful force back operation on a VM, an alert was not cleared.
#4834: After MGMT system reboot, previous alarms that were raised were not cleared in the GUI although the condition returned to normal.
#3905: When unregistering a VC and registering a new VC, the system continued to use the previous VC.
#5161: Streaming Windows 2012R2 to AWS R4 dedicated instance failed to boot.
#5242: Migrated Linux machines to AWS dedicated instance would not boot.
#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 occurs when the VM is started on-premises in a subnet that is enabled with DHCP services.
Note: 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 third-party, VM-level backup solution holds a temporary snapshot, the Velostrata periodic write-back operations do not complete even after the backup solution deletes the temporary snapshot. The uncommitted writes counter on the VM shows an increasing size and no consistency checkpoint is created on-premises.
Workaround: Select the Run On-Premises action for the VM and wait for the task to complete, which commits all pending writes. Then select the Run-in-Cloud action again. Note that committing many pending writes might 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, running the Cloud Extension wizard might generate an error “XXXXXXXXXX” upon “Finish”.
Workaround: Un-register the Velostrata plug-in and restart the vSphere Web client service, then re-register the plug-in. Contact support if the 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 fails and gets stuck in the 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: In rare cases, after running a Workload back on-premises. Workload VMDKs 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.
Note: The issue will resolve itself after 1-2 hours.
#2736: During Detach, the 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.
#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: vCenter “Export OVA” operation is available when the 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 the system fails before it is tagged, the instance remains untagged. This does not allow full clean-up or repair of the CE.
Workaround: Manually tag the instance, and then run "Repair".
#3988: AWS: When performing detach or reconfigure actions for a VM in a dedicated instance tenancy type and choosing an instance type that is not supported by AWS for dedicated instances, the instance is unable to run in the cloud.
Workaround: Change the cloud instance type to one that is supported in dedicated instances mode.
#4604: Cloud Extension high availability does not work for workloads running Ubuntu OS with LVM configuration.
#3199: Suse12: Due to a bug in SUSE kernel older than 4.2, configurations that include BTRFS mounts with subvolumes are not supported.
Workaround: Upgrade to SUSE version with Kernel 4.2 (SP2) or above.
#4619: Velostrata telemetry configuration for FE does not update after BE changes.
Workaround: Contact Velostrata technical support to update the FE telemetry configuration.
#4590: Prepare to detach is not grayed out for spot instances (but the operation fails).
Workaround: GUI issue, no functional impact.
#3570: When using the Create Cloud Extension wizard, using illegal http proxy address does not generate a warning message.
Workaround: Delete the CE and then create the CE with a valid http proxy address.
#3142: In rare cases, creating a CE instance may fail; The system restarts the process to recreate the CE instance and fails due to missing instance tags.
Workaround: Manually terminate the CE instance via the AWS console and run Repair CE.
#3133: Run on-premises operation succeeded but the status is marked as failed with error “Failed to consolidate snapshots”
Workaround: Consolidate snapshots via vCenter, and clear the error manually.
#5706: In rare case canceling a task may take time to complete.
Workaround: This is by design due to uninterruptable processes; and canceling tasks may take a while to complete.
#5547: PowerShell client for cloud to cloud Runbook reports errors when running on PS 3.0.
Workaround: Upgrade to Powershell 4.0.
#5425: When logging to runbook first, login to system web page may fail.
Workaround: Log in to system web page using a different browser.
#5299: Vcenter portlet may not show Public IP address for VM that is in Azure cloud.
Note: When adding a public IP address to an Azure Instance after the Run In Cloud operation the Vcenter is not updated.