Running the Migration Wizard

The Migrate wizard in vSphere does the following steps:

  1. Moves the VM to the cloud.
  2. Migrates the storage to the cloud while the VM is running in cloud.
  3. Prepare to detach the VM. This takes the data from the AWS S3 object, Azure blob, or GCP cloud storage and writes it to dedicated disks for the server.

Once the Migrate wizard is completed after several hours, the VM is Ready to Detach. See Detaching the VM.

For Azure, AWS and GCP, there is a built-in recommendation engine that provides cost- and performance-optimized recommendations. In order to provide an effective recommendation, Velostrata recommends monitoring the VM usage for at least 7 active days. For more information, see Monitoring VM Usage.

On-prem VMware to GCP

1. On the vSphere Web Client, select the desired Virtual Machine.

2. Right-click on the required VM and select Velostrata Operations > Migrate.

3. Select the Velostrata Cloud Extension.

4. Define a new name for the Cloud VM (if desired).

5. Click Next.

6. Select the Project and Instance Type (VM size). 

Three options are recommended for performance-optimized VMs, and three options are recommended for cost-optimized VMs. Additional notes: 

  • The prices are for compute cost only and do not include disk and network costs. 
  • If the VM has not been monitored for a sufficient period (7 days), a message appears indicating that the activity duration may be insufficient for accurate recommendations.
  • If the online price list and/or sufficient monitoring periods are not available, no cost-optimized recommendations are provided.  

7. Click Next

8. Select the Storage Policy, that is, either Write Back or Write Isolation. The choice of Storage Policy need to be carefully reviewed, as this will affect the data changes done while running in cloud:

  • Write back (default option):  When running in cloud using the write back policy, all changes in the cloud will be written to the on-premises storage. This write-back activity happens in background, in an interval of 5GB accumulated changes or 1 hour (whatever comes first).
  • Write isolation: When using write isolation policy, all changes done while running in cloud are kept in cloud on the Velostrata Cloud Edge and are not persisted back on-premises. When moving the VM back to run on-premises, it will go back to its state and data point in time captured in the base snapshot. Related Virtual Machines that are moved to cloud together using the Write Isolation policy should be moved back on-premises together to maintain state alignment.

Note: Once the VM is running in cloud, the storage policy may be switched between Write Back and Write Isolation. To do this, right-click the VM and select Reconfigure virtual machine.

9. Click Next.

  1. Select the Storage Policy, that is, either Write Back or Write Isolation. The choice of Storage Policy need to be carefully reviewed, as this will affect the data changes done while running in cloud:
    • Write back (default option):  When running in cloud using the write back policy, all changes in the cloud will be written to the on-premises storage. This write-back activity happens in background, in an interval of 5GB accumulated changes or 1 hour (whatever comes first).
    • Write isolation: When using write isolation policy, all changes done while running in cloud are kept in cloud on the Velostrata Cloud Edge and are not persisted back on-premises. When moving the VM back to run on-premises, it will go back to its state and data point in time captured in the base snapshot. Related Virtual Machines that are moved to cloud together using the Write Isolation policy should be moved back on-premises together to maintain state alignment.

Note: Once the VM is running in cloud, the storage policy may be switched between Write Back and Write Isolation. To do this, right-click the VM and select Reconfigure virtual machine.

  1. Click Next.

9. Select a cloud Subnet. Typically, the selection here would be of a private network subnet. 

10. Enter the required Network Tags (comma separated), for example, velostrata. Network tags are used by networks to identify which instances are subject to certain firewall rules and network routes. For example, if you have several VM instances that are serving a large website, tag these instances with a shared word or term and then use that tag to apply a firewall rule that allows HTTP access to those instances.

11. Select the Instance Service Account (optional). 

12. From the Configure Private IP drop-down list, select Auto to allow an available address on the subnet to be automatically assigned, or Static if a specific address assignment is required.

A. If you select Static, a Static IP field appears. Enter the required static IP for the instance or specify an ENI ID (e.g. eni-xxxxx) to associate a reserved Elastic Network Interface.

13. From the Edge Node drop-down list, select the required node.

14. For External IP, select None, Static and enter the External IP address name (this is the name for an external IP address created on the GCP console previously) or Ephemeral (the external IP is assigned by Google). Notes:

  • This IP appears as the Public IP Address  in the Velostrata Cloud Extension portlet.
  • If you select Ephemeral (the external IP is assigned by Google),  the same setting persists when you detach, cleanup or cancel detach.  
  • If you select static, you will need to populate the external IP address name, too.

15. Click Next.

  1. Select the Disk Type and Service Account.
  2. Click Next.
  1. Review the summary and then click Finish.

The process of running the VM in the cloud and then migrating the VM can be viewed in the Cloud Instance Information portlet on the VM Summary page, and by monitoring the created vSphere task.

Once the Migrate wizard is completed after several hours, the VM is Ready to Detach. See Detaching the VM.

AWS to GCP

During migration of an instance from AWS to GCP, Velostrata takes ownership of the instance disks at AWS. At the end of the process, the original AWS instance remains intact and powered off.

  • Stops the source VM in AWS
  • Creates the Velostrata VM Importer at AWS
  • Attaches the disk from the source VM to the Importer
  • Creates an instance in GCP
  • Streams data from the importer to the GCP Cloud Extension
  • Terminates the importer and re-attaches the disks to the source VM

For detailed instructions on how to migrate VMs from AWS in GCP, please refer to our Runbook Automation section


For clouds and operations supported in previous versions:

On-prem-to-AWS: To run the migration wizard from vSphere:
  1. On the vSphere Web Client, select the desired Virtual Machine.
  2. Right-click on the required VM and select Velostrata Operations > Migrate.
  1. Select the Velostrata Cloud Extension.
  2. Click Next.
  3. Select the Instance Type (VM size). Three options are recommended for performance-optimized VMs, and three options are recommended for cost-optimized VMs.
    Note: The prices are for compute cost only and do not include disk and network costs. Spot and reserved instances may also have price reduction plans.
    Note: If the VM has not been monitored for a sufficient period (7 days), a message appears indicating that the activity duration may be insufficient for accurate recommendations.
    Note: If the online price list is not available, no cost-optimized recommendations are provided.  
  1. Click Next.
  1. Select the Storage Policy, that is, either Write Back or Write Isolation. The choice of Storage Policy need to be carefully reviewed, as this will affect the data changes done while running in cloud:
    • Write back (default option):  When running in cloud using the write back policy, all changes in the cloud will be written to the on-premises storage. This write-back activity happens in background, in an interval of 5GB accumulated changes or 1 hour (whatever comes first).
    • Write isolation: When using write isolation policy, all changes done while running in cloud are kept in cloud on the Velostrata Cloud Edge and are not persisted back on-premises. When moving the VM back to run on-premises, it will go back to its state and data point in time captured in the base snapshot. Related Virtual Machines that are moved to cloud together using the Write Isolation policy should be moved back on-premises together to maintain state alignment.

Note: Once the VM is running in cloud, the storage policy may be switched between Write Back and Write Isolation. To do this, right-click the VM and select Reconfigure virtual machine.

  1. Click Next.
  1. Select the required Network Security Group.

Note: If you do not enter a Network Security Group the default Network Security Group configured for the Cloud Extension is used.

Note: If public access if required from the internet to the VM, a DMZ is required with an associated security group, including appropriate inbound and outbound rules.

  1. Click Next.
  1. Select a Subnet. Typically, the selection here would be of a private network subnet. When Cloud Edge nodes (A, B) are placed in different AZs, the Cloud Edge node in the same AZ as the selected subnet is automatically used, otherwise a manual node selection is required. If left blank, the default selection for this field is the Default Workload Subnet configured for the Cloud Extension.
  2. From the Configure Private IP drop-down list, select Auto to allow an available address on the subnet to be automatically assigned, or Static if a specific address assignment is required.
  3. If you select Static, a Static IP field appears. Enter the required static IP for the instance or specify an ENI ID (e.g. eni-xxxxx) to associate a reserved Elastic Network Interface.
  4. From the Edge Node drop-down list, select the required node. When Cloud Edge nodes are placed in the same Availability Zone (AZ), a manual selection of the Cloud Edge node to use is required.
  5. Click Next.
  1. Select the Storage Type.
  2. Select Encrypt EBS volume, if you are using EBS encryption for native volumes, and from KMS Key ID, select the encryption key alias to be used. If this is not specified, the default key is used.
  3. Click Next.
  1. Review the summary and then click Finish.

The process of running the VM in the cloud and then migrating the VM can be viewed in the Cloud Instance Information portlet on the VM Summary page, and by monitoring the created vSphere task.

Once the Migrate wizard is completed after several hours, the VM is Ready to Detach. See Detaching the VM.

On-prem-to-Azure: To run the migration wizard from vSphere:
  1. On the vSphere Web Client, select the desired Virtual Machine.
  2. Right-click on the required VM and select Velostrata Operations > Migrate.
  1. Select the Velostrata Cloud Extension.
  2. Click Next.
  3. Select the Instance Type (VM size). Three options are recommended for performance-optimized VMs, and three options are recommended for cost-optimized VMs.
    Note: The prices are for compute cost only and do not include disk and network costs. Spot and reserved instances may also have price reduction plans.
    Note: If the VM has not been monitored for a sufficient period (7 days), a message appears indicating that the activity duration may be insufficient for accurate recommendations.
    Note: If the online price list is not available, no cost-optimized recommendations are provided.  
  4. Select whether to Show only types supporting premium storage.
    Note: Instances that use premium storage may have a different cost.
  5. Select the Resource Group and Availability Set.
  6. (Windows) Select whether to use a Cloud-provided license, or if you have an existing on-premises Windows Server/Client license with active Software Assurance (SA), select Hybrid Use Windows Server or Hybrid Use Windows Client to apply the Azure Hybrid Use Benefit.  
  1. Click Next.
  1. Select the Storage Policy, that is, either Write Back or Write Isolation. The choice of Storage Policy need to be carefully reviewed, as this will affect the data changes done while running in cloud:
    • Write back (default option):  When running in cloud using the write back policy, all changes in the cloud will be written to the on-premises storage. This write-back activity happens in background, in an interval of 5GB accumulated changes or 1 hour (whatever comes first).
    • Write isolation: When using write isolation policy, all changes done while running in cloud are kept in cloud on the Velostrata Cloud Edge and are not persisted back on-premises. When moving the VM back to run on-premises, it will go back to its state and data point in time captured in the base snapshot. Related Virtual Machines that are moved to cloud together using the Write Isolation policy should be moved back on-premises together to maintain state alignment.

Note: Once the VM is running in cloud, the storage policy may be switched between Write Back and Write Isolation. To do this, right-click the VM and select Reconfigure virtual machine.

  1. Click Next.
  1. Select the required Network Security Group.

Note: If you do not enter a Network Security Group the default Network Security Group configured for the Cloud Extension is used.

  1. Click Next.
  1. Select a Subnet. Typically, the selection here would be of a private network subnet. When Cloud Edge nodes (A, B) are placed in different AZs, the Cloud Edge node in the same AZ as the selected subnet is automatically used, otherwise a manual node selection is required. If left blank, the default selection for this field is the Default Workload Subnet configured for the Cloud Extension.
  2. From the Configure Private IP drop-down list, select Auto to allow an available address on the subnet to be automatically assigned, or Static if a specific address assignment is required.
  3. If you select Static, a Static IP field appears. Enter the required static IP for the instance or specify an ENI ID (e.g. eni-xxxxx) to associate a reserved Elastic Network Interface.
  4. From the Edge Node drop-down list, select the required node. A manual selection of the Edge Node to use is required. Select Node A or Node B. The default selection is Node A.
  5. Click Next.
  1. Select the Storage Type.
  2. Click Next.
  1. Review the summary and then click Finish.

The process of running the VM in the cloud and then migrating the VM can be viewed in the Cloud Instance Information portlet on the VM Summary page, and by monitoring the created vSphere task.

Once the Migrate wizard is completed after several hours, the VM is Ready to Detach. See Detaching the VM.

To run the migration using PowerShell:
  1. In PowerShell, connect to the Velostrata Manager by running Connect-VelostrataManager.
  1. When prompted enter details for the Server, Username (apiuser) and Password (the subscription ID).
  2. To start the migration run:

Invoke-VelosMigration -StorageSpec <String> [-Id] <String[]> [-StoragePolicy <String>] [-PricingModelType <String>] [-MaxPriceUSD <Nullable`1[Double]>] [-DefinedDurationHours<Nullable`1[Int32]>] -CloudExtension <CloudExtensionDescriptionWrapper> -InstanceType <String> [-SecurityGroupIds <List`1[String]>] [-NetworkTags <List`1[String]>] [-SubnetId <String>] [-TargetInstanceName <String>] [-CloudDetailsName <String>] [-StaticAddress <String>] [-EdgeNode <String>] [-ResourceGroupId <String>] [-AvailabilitySetId <String>] [-AzureHubLicenseType <AzureHubLicenseType>] [-EncryptDisk <SwitchParameter>] [-DiskEncryptionKey <String>] [<CommonParameters>]

The cmdlet invokes the combined actions of Move-VelosVm, Start-VelosStorageMigration and Start-VelosPrepareToDetach.