feat: add ESXi host support for dedicated migration networks

[albertoflorez]

Description

This PR introduces the ability to configure individual ESXi hosts and their specific migration network settings within the MTV VMware Provider.

It includes updates to:

1. AAP Seed: Added a new field esxi_host_list to the VMware Migration Target credential type.
2. MTV Management: New tasks and templates to automate the creation of Kubernetes Secrets and Host resources for each ESXi host.
3. Playbooks & Inventory: Updated structures to allow passing host-specific data (IP, credentials) through AAP and Ansible.

Motivation

By default, MTV communicates with vCenter for disk transfers. In high-scale environments, this can saturate the vCenter management network.

By defining ESXi hosts directly:

• NFC (Network File Copy) Performance: Traffic can be offloaded to dedicated migration networks (e.g., 10Gbps+).
• Stability: Reduces the load on the vCenter API and management stack during large-scale migrations.
• Granular Control: Allows specifying different credentials and IPs for specific hosts within a cluster.

Changes Detail

• aap-seed: Updated the VMware Migration Target credential type to include esxi_host_list. This allows AAP to store host configurations securely.
• mtv_management:
  • Updated _mtv_provider_vmware.yml to loop through the esxi_hosts list.
  • Added logic to create a Secret for each host (<target-name>-<host-id>-secret).
  • Added vmware_esxi_skeleton.yml.j2 to create the MTV Host CRD.
• inventory.yml: Provided an updated example showing the esxi_hosts data structure.

Testing

Validated by creating a VMware Provider in MTV via AAP and verifying that:

1. The provider is created.
2. Individual Host resources are created in the MTV namespace.
3. Secrets for each host are correctly populated and base64 encoded.

[stevefulme1]

Good feature — dedicated migration networks via ESXi Host CRDs is a real need for large-scale migrations. The core Secret + Host resource logic looks solid. A few things to address before merge:

---

1. inventory.yml — examples uncommented with plaintext credentials

The VMware and oVirt example blocks were previously commented out as reference templates. This PR uncomments them, leaving password: changeme, password: pass1, password: pass2, and user: root as active values. Anyone running the inventory as-is will attempt to create real resources against vcsrs00-vc.demo.example.com with dummy creds.

These examples should be re-commented. Having uncommented credentials in a checked-in file is a risk — someone will fork/clone and accidentally push real creds into this structure.

Also a minor indentation inconsistency: the mapping: block under the oVirt example uses 5-space indent where the rest of the file uses 4.

2. No validation on ESXi host entries

The provider-level target validates that host, username, password are present and non-empty. The ESXi host entries (id, ip, user, password) have no equivalent assertion. If someone omits ip or password, the Secret will be created with a base64-encoded empty string rather than failing fast with a clear error.

Suggest adding an assertion block before the Secret creation loop, something like:

- name: _mtv_provider_vmware | Validate ESXi host properties
  ansible.builtin.assert:
    that:
      - "'id' in vmware_esxi"
      - "'ip' in vmware_esxi"
      - "'user' in vmware_esxi"
      - "'password' in vmware_esxi"
    quiet: true
    fail_msg: "ESXi host entry is missing required fields (id, ip, user, password)"
  loop: "{{ mtv_management_populated_vmware_target.esxi_hosts | default([]) }}"
  loop_control:
    loop_var: vmware_esxi
  when:
    - mtv_management_populated_vmware_target.esxi_hosts is defined
    - mtv_management_populated_vmware_target.esxi_hosts | length > 0

3. Fragile from_json in the playbook

esxi_hosts: "{{ vmware_esxi_hosts | default('[]', true) | from_json }}"

This works when the AAP credential injects valid JSON, but if someone passes malformed input (e.g. single-quoted YAML instead of double-quoted JSON), it'll fail with an unhelpful from_json error. Not a blocker, but a try wrapper or a preceding validation task would improve the UX.

4. Minor nits

• Trailing whitespace on several when: and metadata: lines in _mtv_provider_vmware.yml
• The retries: 100 / delay: 10 on the Host resource creation loop is consistent with the existing provider pattern, but inside a loop over N hosts a single misconfigured entry could stall the play for 16+ minutes

---

Everything else looks good — the template is clean, backward compat is maintained (defaults to []), and the AAP credential type integration is well thought out. The esxi_host_list as a multiline JSON blob in the credential type is a reasonable approach for AAP's credential model.

[albertoflorez]

Thanks for the detailed and constructive review! You brought up some great points. I've pushed a new commit addressing all of them:

1. Inventory: Re-commented the example blocks to prevent accidental credential leakage and fixed the indentation on the oVirt mapping block.

2. Validation: Added the assert block for ESXi host entries to fail fast with a clear message if id, ip, user, or password are missing.

3. I've implemented a block/rescue wrapper in the playbook before the role import. It now attempts to parse the JSON and, if it catches a parsing error, it fails gracefully with a human-readable validation message instead of throwing a raw Jinja2 templating error.

4. Minor nits: Cleaned up the trailing whitespaces. Left the retry loop logic as-is to maintain consistency with the existing provider pattern.

Let me know if anything else catches your eye!

[stevefulme1]

All feedback addressed — inventory re-commented, ESXi host validation added, JSON parsing wrapped in block/rescue, indentation fixed. Clean implementation. Approved.