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:
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
Trilio requires this kit for the VM migration feature to work. You can download it from the VMware Customer Connect portal by accessing the link below
Make sure you download the file
Name
Virtual Disk Development Kit (VDDK)
Version
7.0
Size
22.82 MB
MD5
a67ec7cc5c99fa6b0e50e9da1bc6aa25
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:
set
hw_firmware_type
property toUEFI
set
hw_machine_type
property toq35
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:Open Command Prompt as an administrator: Press
Windows Key + R
, typecmd
, and pressCtrl + Shift + Enter
to open an elevated command prompt.Launch Diskpart: Type
diskpart
and pressEnter
.Check the current SAN policy: Type
san
and pressEnter
.Change the SAN policy: If the current policy is Offline Shared or Offline All, type
san policy=OnlineAll
and pressEnter
. You should see a message indicating the policy change was successful.Exit Diskpart: Type
exit
and pressEnter
.
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?