Limitations

Trilio uses a widely used tool virt-v2v for migration which is one of the open-source tools by Red Hat. The below-mentioned limitations are from this tool and thus a limitation for Trilio as well:

• virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM.

• After converting a virtual machine to KVM, the name of the VM's network interface may change, and thus may require manual configuration.

• Trilio does not support nested virtualization OpenStack deployments for VMware migration.

• For Windows VMs, post migration, if the secondary disks are in an Offline state, you would need to log in to the guest VM and manually bring all the attached disks online by following any of the below steps:

  1. Disk Management Console:

     • Open Disk Management. You can do this by searching for "Computer Management" in the taskbar and navigating to Storage > Disk Management.

     • Locate the disk that is listed as Offline.

     • Right-click on the disk and select Online.

  2. Diskpart Command-Line Utility:

     • Open Command Prompt as an administrator.

     • Type diskpart and press Enter.

     • Type list disk and press Enter to display a list of all disks.

     • Identify the offline disk and note its disk number.

     • Type select disk <disk number> and press Enter, replacing <disk number> with the actual disk number.

     • Type online disk and press Enter.

     • Type exit to close Diskpart.

• Windows VMs migrated with the Dry-Run type won't be bootable on OpenStack, as complete boot information won't be available until the guest VM is shut down.

Please refer to Post-Conversion Tasks for more information.

Other Limitations specific to VM Migration:

• If any VM is having independent (i.e. not mounted on "/") /usr partition, then migration of such VM will fail with below error:

virt-v2v: error: inspection could not detect the source guest (or physical
machine).

Assuming that you are running virt-v2v/virt-p2v on a source which is
supported (and not, for example, a blank disk), then this should not
happen.

Inspection field 'i_arch' was 'unknown'.