Chapter 10. Planning a migration of virtual machines from VMware vSphere

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Network maps.
2. Click Create network map > Create with form.

3. Specify the following:

   • Network map name: Name of the network map.
   • Project: Select from the list.
   • Source provider: Select from the list.
   • Target provider: Select from the list.
   • Source network: Select from the list.
   • Target network: Select from the list.
4. Optional: Click Add mapping to create additional network maps, including mapping multiple network sources to a single target network.

5. Click Create.

   Your map appears in the list of network maps.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Network maps.
2. Click Create network map > Create with YAML.
3. Enter the YAML or JSON definitions into the editor, or drag and drop a file into the editor.

4. If you enter YAML definitions, use the following:

   $  cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: NetworkMap
   metadata:
     name: <network_map>
     namespace: <namespace>
   spec:
     map:
       - destination:
           name: <network_name>
           type: pod
         source:
           id: <source_network_id>
           name: <source_network_name>
       - destination:
           name: <network_attachment_definition>
           namespace: <network_attachment_definition_namespace>
           type: multus
         source:
           id: <source_network_id>
           name: <source_network_name>
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   • type: Allowed values are pod, multus, and ignored. Use ignored to avoid attaching VMs to this network for this migration.
   • source: You can use either the id or the name parameter to specify the source network. For id, specify the VMware vSphere network Managed Object Reference (moRef). For more information about retrieving the moRef, see Retrieving a VMware vSphere moRef in Migrating your virtual machines to Red Hat OpenShift Virtualization.
   • <network_attachment_definition>: Specify a network attachment definition for each additional OpenShift Virtualization network.
   • <network_attachment_definition_namespace>: Required only when type is multus. Specify the namespace of the OpenShift Virtualization network attachment definition.
5. Optional: To download your input, click Download.

6. Click Create.

   Your map appears in the list of network maps.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Storage maps.
2. Click Create storage map > Create with form.

3. Specify the following:

   • Map name: Name of the storage map.
   • Project: Select from the list.
   • Source provider: Select from the list.
   • Target provider: Select from the list.
   • Source storage: Select from the list.
   • Target storage: Select from the list.

4. Optional: If this is a storage map for a migration using storage copy offload, specify the following offload options:

   • Offload plugin: Select vSphere XCOPY from the list.
   • Storage secret: Select from the list.

   • Storage product: Select from the list.

     Note

     Storage copy offload is a feature that allows you to migrate VMware virtual machines (VMs) that are in a storage array network (SAN) more efficiently. This feature makes use of the command vmkfstools on the ESXi host, which invokes the XCOPY command on the storage array using an Internet Small Computer Systems Interface (iSCSI) or Fibre Channel (FC) connection. Storage copy offload lets you copy data inside a SAN more efficiently than copying the data over a network. For Migration Toolkit for Virtualization (MTV) 2.11, storage copy offload is available as GA for cold migration and as a Technology Preview feature for warm migration.

     For more information about storage copy offload, see Migrating VMware virtual machines by using storage copy offload.

5. Optional: Click Add mapping to create additional storage maps, including mapping multiple storage sources to a single target storage class.

6. Click Create.

   Your map appears in the list of storage maps.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Storage maps.

2. Click Create storage map > Create with YAML.

   The Create StorageMap page opens.

3. Enter the YAML or JSON definitions into the editor, or drag and drop a file into the editor.

4. If you enter YAML definitions, use the following:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: StorageMap
   metadata:
     name: <storage_map>
     namespace: <namespace>
   spec:
     map:
       - destination:
           storageClass: <storage_class>
           accessMode: <access_mode>
         source:
           id: <source_datastore>
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   • accessMode: Allowed values are ReadWriteOnce and ReadWriteMany.
   • id: Specify the VMware vSphere datastore moRef, for example, datastore-11. For more information about retrieving the moRef, see Retrieving a VMware vSphere moRef in Migrating your virtual machines to Red Hat OpenShift Virtualization.
5. Optional: To download your input, click Download.

6. Click Create.

   Your map appears in the list of storage maps.

Procedure

1. Access the Create provider page for VMware by doing one of the following:

   1. In the Red Hat OpenShift web console, click Migration for Virtualization > Providers.

      1. Click Create Provider.

      2. Select a Project from the list. The default project shown depends on the active project of MTV.

         If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project.

         If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.

      3. Click VMware.

   2. If you have Administrator privileges, in the Red Hat OpenShift web console, click Migration for Virtualization > Overview.

      1. In the Welcome pane, click VMware.

         If the Welcome pane is not visible, click Show the welcome card in the upper-right corner of the page, and click VMware when the Welcome pane opens.

      2. Select a Project from the list. The default project shown depends on the active project of MTV.

         If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project.

         If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.

2. Specify the following fields:

   1. Provider details

      • Provider resource name: Name of the source provider.
      • Endpoint type: Select the vSphere provider endpoint type. Options: vCenter or ESXi. You can migrate virtual machines from vCenter, an ESX/ESXi server that is not managed by vCenter, or from an ESX/ESXi server that is managed by vCenter but does not go through vCenter.
      • URL: URL of the SDK endpoint of the vCenter on which the source VM is mounted. Ensure that the URL includes the sdk path, usually /sdk. For example, https://vCenter-host-example.com/sdk. If a certificate for FQDN is specified, the value of this field needs to match the FQDN in the certificate.

      • VDDK init image: VDDKInitImage path. It is strongly recommended to create a VDDK init image to accelerate migrations. For more information, see Creating a VDDK image.

        Do one of the following:

        • Select the Skip VMWare Virtual Disk Development Kit (VDDK) SDK acceleration (not recommended).
        • Enter the path in the VDDK init image text box. Format: <registry_route_or_server_path>/vddk:<tag>.

        • Upload a VDDK archive and build a VDDK init image from the archive by doing the following:

          • Click Browse next to the VDDK init image archive text box, select the desired file, and click Select.

          • Click Upload.

            The URL of the uploaded archive is displayed in the VDDK init image archive text box.

   2. Provider credentials

      • Username: vCenter user or ESXi user. For example, user@vsphere.local.
      • Password: vCenter user password or ESXi user password.

3. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

4. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

5. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

   Note

   It might take a few minutes for the provider to have the status Ready.

6. Optional: Add access to the UI of the provider:

   1. On the Providers page, click the provider.

      The Provider details page opens.

   2. Click the Edit icon under External UI web link.

   3. Enter the link and click Save.

      Note

      If you do not enter a link, MTV attempts to calculate the correct link.

      • If MTV succeeds, the hyperlink of the field points to the calculated link.
      • If MTV does not succeed, the field remains empty.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Providers.
2. Click the host number in the Hosts column beside a provider to view a list of hosts.
3. Select one or more hosts and click Select migration network.

4. Specify the following fields:

   • Network: Network name
   • ESXi host admin username: For example, root
   • ESXi host admin password: Password
5. Click Save.

6. Verify that the status of each host is Ready.

   If a host status is not Ready, the host might be unreachable on the migration network or the credentials might be incorrect. You can modify the host configuration and save the changes.

Procedure

1. Access the Create OpenShift Virtualization provider interface by doing one of the following:

   1. In the Red Hat OpenShift web console, click Migration for Virtualization > Providers.

      1. Click Create Provider.

      2. Select a Project from the list. The default project shown depends on the active project of MTV.

         If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project.

         If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.

      3. Click OpenShift Virtualization.

   2. If you have Administrator privileges, in the Red Hat OpenShift web console, click Migration for Virtualization > Overview.

      1. In the Welcome pane, click OpenShift Virtualization.

         If the Welcome pane is not visible, click Show the welcome card in the upper-right corner of the page, and click OpenShift Virtualization when the Welcome pane opens.

      2. Select a Project from the list. The default project shown depends on the active project of MTV.

         If the active project is All projects, then the default project is openshift-mtv. Otherwise, the default project is the same as the active project.

         If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with.

2. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

3. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

4. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

5. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Providers.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Provider details page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

6. Configure a gateway in the network used for MTV migrations by completing the following steps:

   1. In the Red Hat OpenShift web console, click Networking > NetworkAttachmentDefinitions.
   2. Select the appropriate default transfer network NAD.
   3. Click the YAML tab.

   4. Add forklift.konveyor.io/route to the metadata:annotations section of the YAML, as in the following example:

      apiVersion: k8s.cni.cncf.io/v1
      kind: NetworkAttachmentDefinition
      metadata:
        name: localnet-network
        namespace: mtv-test
        annotations:
          forklift.konveyor.io/route: <IP address>

      • The NetworkAttachmentDefinition parameter is needed to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. Configuring the IP address enables the interface to reach the configured gateway.
   5. Click Save.

Procedure

1. On the Red Hat OpenShift web console, click Migration for Virtualization > Migration plans.

2. Click Create plan.

   The Create migration plan wizard opens.

3. On the General page, specify the following fields:

   • Plan name: Enter a name.
   • Plan project: Select from the list.
   • Source provider: Select from the list.
   • Target provider: Select from the list.

   • Target project: Click the list and do one of the following:

     1. Select an existing project from the list.

     2. Create a new project by clicking Create project and doing the following:

        1. Enter the Name of the project. A project name must consist of lowercase alphanumeric characters or -. A project name must start and end with alphanumeric characters. For example, my-name or 123-abc.
        2. Optional: Enter a Display name for the project.
        3. Optional: Enter a Description of the project.
        4. Click Create project.
4. Click Next.
5. On the Virtual machines page, select the virtual machines you want to migrate and click Next.
6. If you are using a UDN, verify that the IP address of the provider is outside the subnet of the UDN. If the IP address is within the subnet of the UDN, the migration fails.

7. On the Network map page, choose one of the following options:

   • Use an existing network map: Select an existing network map from the list.

     These are network maps available for all plans, and therefore, they are ownerless in terms of the system. If you select this option and choose a map, a copy of that map is attached to your plan, and your plan is the owner of that copy. Any changes you make to your copy do not affect the original plan or any copies that other users have.

     Note

     If you choose an existing map, be sure it has the same source provider and the same target provider as the ones you want to use in your plan.

   • Use a new network map: Allows you to create a new network map by supplying the following data. This map is attached to this plan, which is then considered to be its owner. Maps that you create using this option are not available in the Use an existing network map option because each is created with an owner.

     Note

     You can create an ownerless network map, which you and others can use for additional migration plans, in the Network maps section of the UI.

     • Source network: Select from the list.

     • Target network: Select from the list.

       If needed, click Add mapping to add another mapping.

     • Network map name: Enter a name or let MTV automatically generate a name for the network map.
8. Click Next.

9. On the Storage map page, choose one of the following options:

   • Use an existing storage map: Select an existing storage map from the list.

     These are storage maps available for all plans, and therefore, they are ownerless in terms of the system. If you select this option and choose a map, a copy of that map is attached to your plan, and your plan is the owner of that copy. Any changes you make to your copy do not affect the original plan or any copies that other users have.

     Note

     If you choose an existing map, be sure it has the same source provider and the same target provider as the ones you want to use in your plan.

   • Use new storage map: Allows you to create one or two new storage maps by supplying the following data. These maps are attached to this plan, which is then their owner. Maps that you create using this option are not available in the Use an existing storage map option because each is created with an owner.

     Note

     You can create an ownerless storage map, which you and others can use for additional migration plans, in the Storage maps section of the UI.

     • Source storage: Select from the list.

     • Target storage: Select from the list.

       If needed, click Add mapping to add another mapping.

     • Storage map name: Enter a name or let MTV automatically generate a name for the storage map.
10. Click Next.

11. On the Migration type page, choose one of the following:

    • Cold migration (default)
    • Warm migration
12. Click Next.

13. On the Other settings (optional) page, specify any of the following settings that are appropriate for your plan. All are optional.

    • Disk decryption passphrases: For disks encrypted using Linux Unified Key Setup (LUKS).

      • Enter a decryption passphrase for a LUKS-encrypted device.
      • To add another passphrase, click Add passphrase and add a passphrase.

      • Repeat as needed.

        You do not need to enter the passphrases in a specific order. For each LUKS-encrypted device, MTV tries each passphrase until one unlocks the device.

    • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization. This is the default transfer network of the provider.

      • Verify that the transfer network is in the selected target project.
      • To choose a different transfer network, select a different transfer network from the list.

      • Optional: To configure another OpenShift network in the OpenShift web console, click Networking > NetworkAttachmentDefinitions.

        To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

      • To adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information, see Selecting a migration network for a VMware source provider.

    • Preserve static IPs: By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP linked to the interface name in the guest VM lose their IP during migration.

      • To preserve static IPs, select the Preserve the static IPs checkbox.

        MTV then issues a warning message about any VMs whose vNIC properties are missing. To retrieve any missing vNIC properties, run those VMs in vSphere. This causes the vNIC properties to be reported to MTV.

    • Root device: Applies to multi-boot VM migrations only. By default, MTV uses the first bootable device detected as the root device.

      • To specify a different root device, enter it in the text box.

        MTV uses the following format for disk location: /dev/sd<disk_identifier><disk_partition>. For example, if the second disk is the root device and the operating system is on the disk’s second partition, the format would be: /dev/sdb2. After you enter the boot device, click Save.

        If the conversion fails because the boot device provided is incorrect, it is possible to get the correct information by checking the conversion pod logs.

    • Shared disks: Applies to cold migrations only. Shared disks are disks that are attached to multiple VMs and that use the multi-writer option. These characteristics make shared disks difficult to migrate. By default, MTV migrates shared disks.

      Note

      Migrating shared disks might slow down the migration process.

      • To migrate shared disks in the migration plan, verify that Shared disks is selected in the checkbox.
      • To avoid migrating shared disks, clear the Shared disks checkbox.
14. Click Next.
15. On the Hooks (optional) page, you can add a pre-migration hook, a post-migration hook, or both types of migration hooks. All are optional.
16. To add a hook, select the appropriate Enable hook checkbox.
17. Enter the Hook runner image.

18. Enter the Ansible playbook of the hook in the window.

    Note

    You cannot include more than one pre-migration hook or more than one post-migration hook in a migration plan.

19. Click Next.
20. On the Review and create page, review the information displayed.

21. Edit any item by doing the following:

    1. Click its Edit step link.

       The wizard opens to the page where you defined the item.

    2. Edit the item.
    3. Either click Next to advance to the next page of the wizard, or click Skip to review to return directly to the Review and create page.

22. When you finish reviewing the details of the plan, click Create plan.

    MTV validates your plan. When your plan is validated, the Plan details page for your plan opens. If everything is OK, the Plan details page for your plan opens. This page contains important settings that do not appear in the wizard.

Procedure

1. On the Plan details page for your plan, review the Plan settings section.

   The Plan settings section includes settings that you specified in the Other settings (optional) page of the wizard and some additional optional settings. The steps below refer to the additional optional settings, but all of the settings can be edited by clicking the Options menu , making the change, and then clicking Save.

2. Check the following items in the Plan settings section of the page:

   1. Volume name template: Specifies a template for the volume interface name for the VMs in your plan.

      For a list of available variables and examples, see Volume name template variables.

      • To specify a volume name template for all the VMs in your plan, do the following:

        • Click the Edit icon.
        • Click Enter custom naming template.
        • Enter the template according to the instructions. Be sure that your template generates volume names that are DNS-compliant.
        • Click Save.

      • To specify a volume name template only for specific VMs, do the following:

        • Click the Virtual Machines tab.
        • Select the desired VMs.
        • Click the Options menu of the VM.
        • Select Edit Volume name template.
        • Enter the template according to the instructions. Be sure that your template generates volume names that are DNS-compliant.
        • Click Save.

   2. PVC name template: Specifies a template for the name of the persistent volume claim (PVC) for the VMs in your plan.

      For a list of available variables, template functions, and examples, see PVC name template variables.

      • To specify a PVC name template for all the VMs in your plan, do the following:

        • Click the Edit icon.
        • Click Enter custom naming template.
        • Enter the template according to the instructions. Be sure that your template generates PVC names that are DNS-compliant.
        • Click Save.

      • To specify a PVC name template only for specific VMs, do the following:

        • Click the Virtual Machines tab.
        • Select the desired VMs.
        • Click the Options menu of the VM.
        • Select Edit PVC name template.
        • Enter the template according to the instructions. Be sure that your template generates PVC names that are DNS-compliant.
        • Click Save.

   3. Network name template: Specifies a template for the network interface name for the VMs in your plan.

      For a list of available variables and examples, see Network name template variables.

      • To specify a network name template for all the VMs in your plan, do the following:

        • Click the Edit icon.
        • Click Enter custom naming template.
        • Enter the template according to the instructions. Be sure that your template generates network interface names that are DNS-compliant.
        • Click Save.

      • To specify a network name template only for specific VMs, do the following:

        • Click the Virtual Machines tab.
        • Select the desired VMs.
        • Click the Options menu of the VM.
        • Select Edit Network name template.
        • Enter the template according to the instructions. Be sure that your template generates network interface names that are DNS-compliant.

        • Click Save.

          Important

          Changes you make on the Virtual Machines tab override any changes on the Plan details page.

          Important

          You must ensure that the templates you enter on the Plan details page generate DNS-compliant names. If the template syntax is invalid or if the resulting names are not DNS-compliant, MTV adds an error to the plan conditions and prevents the migration from running. To help ensure valid names, you might want to run a Go script that uses the sprig methods that MTV supports. For tables documenting the methods that MTV supports, see MTV template utility for VMware.

   4. Raw copy mode: By default, during migration, virtual machines (VMs) are converted using a tool named virt-v2v that makes them compatible with OpenShift Virtualization. For more information about the virt-v2v conversion process, see How MTV uses the virt-v2v tool. Raw copy mode copies VMs without converting them. This allows for faster conversions, migrating VMs running a wider range of operating systems, and supporting migrating disks encrypted using Linux Unified Key Setup (LUKS) without needing keys. However, VMs migrated using raw copy mode might not function properly on OpenShift Virtualization.

      • To use raw copy mode for your migration plan, do the following:

        • Click the Edit icon.
        • Toggle the Raw copy mode switch to enable it.

        • Optional: Configure the Use compatibility mode setting:

          When you enable Use compatibility mode (default), MTV uses compatibility devices (SATA bus, E1000E NICs, USB) to ensure the VM can boot on OpenShift Virtualization.

          When you disable Use compatibility mode, MTV uses pre-installed VirtIO devices on the source VM for better performance.

          Important

          Only disable Use compatibility mode if VirtIO drivers are already installed in the source VM. VMs without pre-installed VirtIO drivers do not boot on OpenShift Virtualization if you disable compatibility mode.

        • Click Save.

   5. VM target node selector, VM target labels, and VM target affinity rules are options that support VM target scheduling, a feature that lets you direct MTV to migrate virtual machines (VMs) to specific nodes or workloads (pods) of OpenShift Virtualization as well as to schedule when to power on the VMs.

      For more information on the feature in general, see Target VM scheduling options.

      For more details on using the feature with the UI, see Scheduling target VMs from the user interface.

      • VM target node selector allows you to create mandatory exact match key-value label pairs that the target node must possess. If no node on the cluster has all the labels specified, the VM is not scheduled and it remains in a Pending state until there is space on a node that fits these key-value label pairs.

        • To use the VM target node selector for your migration plan, do the following:

          • Click the Edit icon.
          • Enter a key-value label pair. For example, to require that all VMs in the plan be migrated to your east data center, enter dataCenter as your key and east as your label.
          • To add another key-value label pair, click + and enter another key-value pair.
          • Click Save.

      • VM target labels allows you to apply organizational or operational labels to migrated VMs for identification and management. One use for these labels is to use them to specify a different scheduler for your migrated VMs, by creating a specific target VM label for it.

        • To use the VM target node selector for your migration plan, do the following:

          • Click the Edit icon.
          • Enter one or more VM target labels.
          • Click Save.

      • VM target affinity rules: Target affinity rules let you use conditions to either require or prefer scheduling on specific nodes or workloads (pods).

        Target anti-affinity rules let you prevent VMs from being scheduled to run on selected workloads (pods) or prefer that they are not scheduled. These kind of rules offer more flexible placement control than rigid Node Selector rules, because they support conditionals such as In, or NotIn.

        For example, you could require that a VM be powered on "only if it is migrated to node A or if it is migrated to an SSD disk, but it cannot be migrated to a node for which license-tier=silver is true."

        Additionally, both target affinity and target anti-affinity rules allow you to include both hard and soft conditions in the same rule. A hard condition is a requirement, and a soft condition is a preference. The previous example used only hard conditions. A rule that states that "a VM can be powered on if it is migrated to node A or if it is migrated to an SSD disk, but it is preferred not to migrate it to a node for which license-tier=silver is true" is an example of a rule that uses soft conditions.

        MTV supports target affinity rules at both the node level and the workload (pod) level. It supports anti-affinity rules at the workload (pod) level only.

        • To use VM target affinity rules for your migration plan, do the following:

          • Click the Edit icon.
          • Click Add affinity rule.
          • Select the Type of affinity rule from the list. Valid options: Node Affinity, Workload (pod) Affinity, Workload (pod) Anti-Affinity.
          • Select the Condition from the list. Valid options: Preferred during scheduling (soft condition), Required during scheduling (hard condition).
          • Soft condition only: Enter a numerical Weight. The higher the weight, the stronger the preference. Valid options: whole numbers from 1-100.
          • Enter a Typology key, the key for the node label that the system uses to denote the domain.

          • Optional: Select the Workload labels that you want to set by doing the following:

            • Enter a Key.
            • Select an Operator from the list. Valid options: Exists, DoesNotExist, In, and NotIn.
            • Enter a Value.
          • To add another label, click Add expression and add another key-value pair with an operator.
          • Click Save affinity rule.

          • To add another affinity rule, click Add affinity rule. Rules with a preferred condition will stack with an AND relation between them. Rules with a required condition will stack with an OR relation between them.

            MTV validates any changes you made on this page.

3. In addition to listing details based on your entries in the wizard, the Plan details tab includes the following two sections after the details of the plan:

   • Migration history: Details about successful and unsuccessful attempts to run the plan
   • Conditions: Any changes that need to be made to the plan so that it can run successfully

4. When you have fixed all conditions listed, you can run your plan from the Plans page.

   The Plan details page also includes five additional tabs, which are described in the table that follows:

   Expand

   Table 10.11. Tabs of the Plan details page

   YAML	Virtual Machines	Resources	Mappings	Hooks
   Editable YAML Plan manifest based on your plan’s details including source provider, network and storage maps, VMs, and any issues with your VMs	The VMs the plan migrates	Calculated resources: VMs, CPUs, and total memory for both total VMs and running VMs	Editable specification of the network and storage maps used by your plan	Updatable specification of the hooks used by your plan, if any

   Show more

Procedure

1. Enable NBDE with Clevis in the MTV UI.

   1. In the Create migration plan wizard, navigate to Other settings under Additional setup in the left navigation pane.

   2. Select Use NBDE/Clevis.

      If you are not using NBDE with Clevis, you add passphrases for LUKS-encrypted devices so that the Tang servers can decrypt the disks during a migration.

   3. Click Next, and verify that Use NBDE/Clevis shows as Enabled under Other settings (optional).
   4. When you create your migration plan, click Migration plans in the left navigation menu, and open the Plan details page for your migration plan.
   5. Click the Edit icon for Disk decryption under Plan settings.

   6. Verify that Use network-bound disk encryption (NBDE/Clevis) is selected.

      If you are not using NBDE with Clevis, verify that the passphrases for LUKS-encrypted devices are added.

2. Enable NBDE with Clevis in the YAML file.

   1. Click Migration plans in the left navigation menu and open the Plan details page for your migration plan.
   2. Click the YAML tab to open the Plan custom resource (CR) for your migration plan.

   3. For each VM under vms in the YAML file, enter the encryption type. In this example, you set nbdeClevis as the encryption type for vm-1, LUKS passphrase as the encryption type for vm-2, and no encryption type for vm-3:

      Example:

      vms:
        - id: vm-1
          name: vm-1-esx8.0-rhel8.10-raid1
          targetPowerState: on
          nbdeClevis: true
        - id: vm-2
          name: vm-2-esx8.0-rhel8.10-raid1
          luks: { name: 'test-secret-1' }
        - id: vm-3
          name: vm-3-esx8.0-rhel8.10-raid1