Velostrata v3.5 Release Notes
Velostrata V3.5 introduced an enhanced WebUI which includes the following components:
vCenter plugin setting
CE deployment and monitoring
Runbook Job monitoring
Deployment of Velostrata Manager at GCP
Velostrata V3.5 supports deploying the Velostrata Manager at GCP. This allows customer that have no vSphere setup to deploy the Manager in cloud for AWS->GCP migrations.
Runbook support for vSphere to Cloud
Velostrata (new) Runbook application is now supporting on-prem -> cloud migrations in addition to AWS-> GCP migrations. In addition to Jobs and Job monitoring, you can now Rerun a job at any point in time, the system will assess the Runbook vs. actual states and will act accordingly to get to the desired state described in the Runbook definition.
Support for Migration of UEFI based VM
Velostrata V3.5 now supports migration of VMs that are configured with UEFI BIOS setting to cloud (which currently supports only legacy BIOS). During the migration the boot disk layout will be altered to support MBR boot. Please note that Write-Back is not supported with VMs that are configured with UEFI BIOS at the source.
Right Sizing enhancements
Velostrata V3.5 Right Sizing feature add support recommending custom instances at GCP where applicable.
Attaching GCP Service Account to migrated Instances.
Velostrata V3.5 allows the user to define a GCP Service Account to be attached to a migrated instance.
Cloud Extensions performance improvements
Various improvements to cache logic and disk access which improve overall system performance
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, 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 22.214.171.124 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
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 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 (64 bit)
Windows Server 2008 R2 SP1 or higher.
Windows Server 2012/Windows Server 2012 R2.
Windows server 1709
Supported Windows Versions with Offline Migration(see further details in Using Offline Migration):
Windows Server 2003, Windows Server 2003R2, Windows Server 2008
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, 18.04.x
Supported Linux Versions in Offline Migration (see further details in Using Offline Migration):
RHEL 5.1 or higher 64-bit RHEL 5.11 and higher supported also with 32-bit
Note: Block device naming considerations differ across target cloud provider and depend on 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.
#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.
Workaround: 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 Command prompt as an Administrator and run the following: nvspbind.exe /d * symc_teefer2.
Known Instance Type Compatibility Issues
Paravirtualized (PV ) instance types are not supported.
The following AWS instance types may experience host missing driver issues. Refer to the AWS driver lists for specific kernel and driver information.
M5 and C5 types are not supported at this time for direct migrations. Customer can switch to these type post migration (will require installation of the relevant drivers).
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 known issues:
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 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.
#5706: In rare case canceling task may take time to complete.
#5425: When logging to runbook first, login to system web page may fail
#5299: Vcenter portlet may not show Public IP address for VM that is in Azure cloud
#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.
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 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, 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 will fail and get 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 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.
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 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".
#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.
#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).
#4619: Velostrata telemetry configuration for FE will 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 will 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 will restart the process to recreate the CE instance and will fail due to missing instance tags.
Workaround: Manually terminate the CE instance via the AWS console, and run Repair CE.
#3133: Run on-premise 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.
#5547: PowerShell client for cloud to cloud Runbook reports errors when running on PS 3.0
Workaround: Upgrade to Powershell 4.0
#5387: CentOS6 cannot boot in AWS m4 instance type.
Workaround: Use different instance type for migration phase, switch to m4 instance type post migration.
#5700: RHEL 6.5 may occasionally fail to boot at AWS
Workaround: Move back to source and retry
#6095: RHEL-7.5_HVM_GA-20180322-x86_64-1-Hourly2-GP2 (ami-7c491f05) based instance migrated from AWS to GCP will not boot at GVP
Workaround: Contact Velostrata support prior migrating instance based on this image
#6026: On rare case Ubuntu based instance may hang at first boot in cloud
Workaround: Reboot the instance from GCP console
#6024: When login to the System Setting section in the Web UI with “apiuser” the system returns 403
Workaround: Reopen the page with incognito mode.
#6007: When migrating Windows system to dedicated R4.xlarge instance at AWS the instance will not boot.
Workaround: use different type of instance.
#5974: When migrating Windows system to dedicated R4.xlarge instance at AWS the instance will not boot.
Workaround: use different type of instance.
#5387: CentOS6 may hang 2-3 minutes after booting in dedicate m4.large instance
Workaround: use different type of instance.
#5709: When migrating RHEL 7.4 from AWS to GCP, GCP agent will not be installed automatically.
Workaround: Manually remove AWS agent and install GCP agent
#5974: In certain environments with high latency between Velostrata Management appliance and vCenter, restart of Velostrata Management appliance may cause VMs in cloud and their data migration to be stuck.
Workaround:Potential workarounds (one of):
1. Reduce latency between Velostrata Management appliance and vCenter
2. Reduce load on vCenter
3. Reduce number of concurrently migrated VMs
4. Increase backend health-check retry intervals