Network Latency and Migrations
When using VirtaMove to migrate applications to the Cloud or to migrate applications off-premises, network latency can greatly increase the time it takes to copy files and perform registry changes. Roundtrip latency mainly impacts Windows Remote Registry Protocol (MS-RRP), which is used to manipulate the Windows registry on the destination machine.
If your scenario involves migrating applications on-premise to the Cloud or off-premises, and you are not sure about network latency between the source and destination machines, VirtaMove recommends that you test migration using a simple, small application, such as Notepad++. Notepad++ is 17 MB on disk and should take no more than 5 minutes to migrate from the source to the destination environment. If the migration takes longer than 5 minutes, you can be reasonably sure that there is latency somewhere in the network. Testing a simple, small application like Notepad++ in your environment will identify potential latency and allow you to determine approximately how long larger applications will take to migrate. It's important to set clear expectations concerning how long a migration is expected to take, for the sake of resource planning and coverage during the change management window.
If latency is a known constraint in your environment, VirtaMove recommends that you use an interim server in a migration. Using an interim server provides the best strategy for migrating applications across high latency connections using VirtaMove. The interim server is provisioned with the operating system version of the intended destination machine, and placed in close proximity to the source server. The VirtaMove Tether and migration processes happen from the source server to the interim server. Then, the container is compressed and copied to the destination server off-premises. Once the compressed container has been copied successfully, it is uncompressed and finally dissolved onto the destination server, thus completing the migration.
Performing migrations using an interim server ensures that files and registry artifacts are copied with minimal latency; this saves a great deal of time during the pre-populate part of the migration and when you exercise the tethered application. Moving one larger file (a compressed container stored as a .cap file) is the optimal way to move the contained application(s).
Requirements for Using an Interim Server
The https://virtamove.atlassian.net/wiki/spaces/VDOC/pages/310706978 for interim servers are the same as those for destination servers. In particular:
the interim and destination servers must use the same version of the operating system
the interim and destination servers must have the same drive layout as the source machine – the same drive letter and enough space for the application(s)
the interim server requires enough disk space for the container plus a compressed copy of the container (roughly 50% of the container size on disk)
the interim server should be on the same Local Area Network as the source server
Re-Using an Interim Server
You cannot re-use an interim server to migrate different applications successively. This is because when a container is docked, a few artifacts such as users, groups, and some side-by-side assemblies are pushed to the underlying operating system; if the same artifacts exist in a subsequent application, their presence in the underlying operating system will cause them to be excluded from the container. To re-use interim servers effectively, VirtaMove recommends that you use virtual servers that can be recycled, or that you take a virtual machine snapshot before migration and then restore to that snapshot after every migration. With access to the Hypervisor management layer, a migration specialist can quickly snapshot and revert, as well as change disk layout on the interim server to match the next source server.
Interim Servers and Parallel Migrations
For parallel migrations, VirtaMove recommends that you have more than one interim server. A parallel migration may involve migrating different parts of the application architecture in parallel (database server, middleware server, presentation or Web server). In factory models, several migration streams may run in parallel.
Testing Network Latency
You can test your network for possible latency issues, which could make the migration of a large application a very lengthy process. Many hops on the network, a low transfer rate, or many packets lost could indicate network latency. VirtaMove automatically tests latency on your network when you attempt to find applications on the source server.
The Test Latency button on the Tether tab of the Administration Console provides the following information about your network:
Ping - displays ping statistics for the source machine, including packets sent, received, and lost, as well as round trip time in ms
Trace Route - displays the number of hops on the network and the average round trip time between local and remote machines
Transfer Rate - displays the transfer rate per second
To Test Latency on Your Network
In the Tether tab of the Administration Console, click the Test Latency button. The Latency Test Results window appears.
Review the information on the following tabs as appropriate:
Ping
Trace Route
Transfer Rate
Close the Latency Test Results window when you are done.
https://virtamove.atlassian.net/wiki/spaces/VDOC/pages/311394343/Performing+a+Staged+Application+Migration?search_id=cdddc93e-f1e1-4d0e-8e5a-407213851ac3