GeezerVison

Description

This PR...
Host-side verification (new)

• helpers/kvm_host.py: helpers over SSH for service state, virsh domain state and XML, by-id block devices, iSCSI sessions, and the LUN serial to WWID mapping.
• ontap_test_base.py: _assert_kvm_hosts_ready (fails the class early if libvirtd, the agent or iscsid is down or the host is not Up), _vm_placement, _assert_vm_disks_on_host, _assert_domain_absent, _assert_devices_gone, _assert_disk_detached_on_host, _assert_iscsi_session_to_svm, and _iscsi_host_specs (reads host IQNs over SSH).

igroup semantics (the driver behavior these tests now match)

• The host igroup cs_<hostUuid>_<svm> is created lazily at first volume access (grantAccess), not at pool creation.
• It is shared across pools and removed by ONTAP itself (delete_on_unmap) when its last LUN is unmapped. deleteDataStore does not delete it.
• New _assert_host_igroups_follow_lun_maps: the igroup must exist exactly while a LUN is mapped to it. New OntapRestClient.list_lun_maps_for_igroup supports this. Pool-only steps use the existing _assert_igroup_baseline_unchanged.

VM placement

• _discover_vm_deploy_resources(storage_tags=...) creates a compute offering tagged with the pool's storage tag, deleted in tearDownClass. The previous untagged offering let the root disk land on any shared pool, for example Primary1 (NFS).
• test_16 also fails early, naming any other enabled pool with the same tag. The placement assertion now says which pool the disk landed on.

Test cases changed

iSCSI pool lifecycle (iscsi/pool/test_pool_lifecycle.py)

iSCSI VM and volume attach (iscsi/instance/test_vm_volume_attach.py)

• test_03_deploy_vm, test_03a_deploy_second_vm_reuses_template_cache, test_03b_expunge_second_vm_template_cache_survives, test_04_attach_volume_to_vm, test_05_stop_vm_lun_unmapped, test_08_start_vm_lun_remapped, test_24_detach_volume_from_vm, test_27_destroy_vm_and_cleanup: add host-side checks after each step. The domain is running with the right XML and by-id devices, the disk capacity matches, and after stop, detach or destroy the domain and devices are gone. _start_vm and _stop_vm now do the same checks.

iSCSI volume lifecycle (iscsi/volume/test_volume_lifecycle.py)

• test_05_delete_volume_and_force_delete_pool: the igroup check now uses the driver's real name, cs_<hostUuid>_<svm>, so it can fail.

Template-cache negative workflow (helpers/template_cache_negative_workflow.py, shared by iSCSI and NFS3)

• step_03_deleted_cache_blocks_reuse: the seed-VM host checks and the cache-LUN mapping check are iSCSI-only, so they are now guarded by the protocol check. Previously the NFS3 run asserted an igroup for an NFS pool.

NFS3 pool lifecycle (nfs3/pool/test_pool_lifecycle.py)

• test_06_reject_grow_above_max_size: same precondition change as iSCSI. NFS pools report host-measured usable space, which is 95% of the FlexVol with the default snapshot reserve (285 TiB for 300 TiB), refreshed periodically. The over-max request (MAX + 1 GiB) and the "unchanged" checks are unchanged.

Docs: README.md lists the new helpers.

Verification (single-host lab, KVM + ONTAP)

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?