# 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:

<table><thead><tr><th width="365">Privilege Level</th><th>Required Permissions</th></tr></thead><tbody><tr><td>Datastore</td><td><ul><li>Browse datastore</li><li>Low level file operations</li></ul></td></tr><tr><td>Sessions</td><td><ul><li>Validate session</li></ul></td></tr><tr><td>Virtual machine / Interaction</td><td><ul><li>Guest operating system management by VIX API</li><li>Power off</li><li>Power on</li></ul></td></tr><tr><td>Virtual machine / Provisioning</td><td><ul><li>Allow disk access</li><li>Allow read-only disk access</li><li>Allow virtual machine download</li></ul></td></tr><tr><td>Virtual machine / Snapshot management</td><td><ul><li>Create snapshot</li><li>Remove snapshot</li></ul></td></tr></tbody></table>

**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
* ​<https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/7.0>​
* 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:
  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](https://kb.vmware.com/s/article/1020128)

Also understand the limitations Trilio has described in [this page](https://docs.trilio.io/openstack/t4o-5.x/deployment/software-driven-migration-vmware-to-openstack/limitations).

### 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](https://en.wikipedia.org/wiki/Chattr) set. You can use the [chattr(1)](http://man.he.net/man1/chattr) 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](https://libguestfs.org/virt-v2v.1.html#converting-a-windows-guest) for other requirements and notes.