Preparations

Preparing vCenter + OpenStack + Trilio

You will need to be ready with the following resources before starting with the deployment:

VMware Resources

vCenter access information

  • vCenter access URL

  • vCenter access Username and Password

  • SSL certificate for secured connection to VCenter (if not available, the SSL verification has to be marked false during configuration)

  • The minimum set of permissions required for a vCenter user to successfully migrate VMs are as follows:

Privilege Level
Required Permissions

Datastore

  • Browse datastore

  • Low level file operations

Sessions

  • Validate session

Virtual machine / Interaction

  • Guest operating system management by VIX API

  • Power off

  • Power on

Virtual machine / Provisioning

  • Allow disk access

  • Allow read-only disk access

  • Allow virtual machine download

Virtual machine / Snapshot management

  • Create snapshot

  • Remove snapshot

Network Port Requirement

Trilio needs to have below port accesses for the VM migration feature to work:

  • On vCenter:

    • 80, 443: bi-directional access to OpenStack controller and compute nodes

  • On ESXi hosts:

    • 80,443: bi-directional access to vCenter, OpenStack controller, and compute nodes

    • 902: outgoing access to vCenter, OpenStack compute nodes

VMware vSphere Virtual Disk Development Kit 7.0

OpenStack Resources

Glance Images

  • For migrating UEFI booted VMware VMs, the OpenStack requires to have the instances with UEFI boot information and so as Trilio.

  • So before doing the migration, the user needs to create a Glance image (any image) with following metadata properties:

    1. set hw_firmware_type property to UEFI

    2. set hw_machine_type property to q35

  • This is not required for BIOS booted VMware VMs

Instace Flavors

  • Trilio does not create any flavor for the migrating VMs instead it uses the available flavors.

  • To avoid any booting issues post-migration, the user needs to have the correct flavors created and available for selection while initiating the migration.

Preparing the Guest VMs on ESXi

Windows VMs Preparation

  • VMware tools need to be installed and should be running on all the Windows OS VMs that are to be migrated. Alternatively, the guest OS must be in a Shutdown state and not be in a Power-off state.

  • Secondary disks in Windows Server VMs appear offline after migration.

    To avoid the disks going into an offline state, set the SAN policy OnlineAll in the guest VM before the migration. Steps to change the SAN policy:

    1. Open Command Prompt as an administrator: Press Windows Key + R, type cmd, and press Ctrl + Shift + Enter to open an elevated command prompt.

    2. Launch Diskpart: Type diskpart and press Enter.

    3. Check the current SAN policy: Type san and press Enter.

    4. Change the SAN policy: If the current policy is Offline Shared or Offline All, type san policy=OnlineAll and press Enter. You should see a message indicating the policy change was successful.

    5. Exit Diskpart: Type exit and press Enter.

  • This is not mandatory for migration, as the disks can be brought to the Online state manually post-migration as well.

Enable Change Block Tracking

To leverage the Dry-run and Warm migration features, the vCenter and ESXi should support the Change Block Tracking(CBT) feature. Make sure that all the data disks attached to the VM, have the CBT enabled.

To enable the CBT, follow the instructions at VMware Knowledge Base

Also understand the limitations Trilio has described in this page.

Free space in the guest for conversion

Virt-v2v checks if there is sufficient free space in the guest filesystem to perform the conversion. Currently, it checks:

  • Linux root filesystem

    • Minimum free space: 100 MB

  • Linux /boot

    • Minimum free space: 50 MB This is because we need to build a new initramfs for some Enterprise Linux conversions.

  • Windows C: drive

    • Minimum free space: 100 MB We may have to copy in many virtio drivers and guest agents.

  • Any other mountable filesystem

    • Minimum free space: 10 MB

In addition to the actual free space, each filesystem is required to have at least 100 available inodes.

Access to "/etc/resolv.conf"

In a Linux guest, you see an error such as this:

virt-v2v: error: libguestfs error: command lines: rename: /sysroot/etc/resolv.conf to /sysroot/etc/lwdhuh36: Operation not permitted

This can be caused because the file /etc/resolv.conf in the guest has the immutable bit set. You can use the chattr(1) command before converting the guest:

chattr -i /etc/resolv.conf

and then restore it (+i) after conversion.

In addition, please refer to the virt-v2v upstream documentation for other requirements and notes.

Last updated

Was this helpful?