[sandeeplocharla]

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)

Test	Change	Reason
setUpClass	Capture the igroup baseline; create the tagged offering	Pool steps must leave shared igroups untouched; deterministic VM placement
test_03_create_primary_storage_pool	Assert igroups unchanged after creation	The driver creates igroups lazily, so none exist yet
test_05, test_07, test_09, test_12 (grow, shrink, resize while disabled or in maintenance)	Replace the skipped per-host igroup loops with baseline-unchanged checks	The old checks never ran and used the wrong name
test_06_reject_grow_above_max_size	Precondition is now the ONTAP FlexVol size (space.size) equal to 300 TiB	The old precondition compared CloudStack's reported capacity, which differs by protocol
test_14_enter_maintenance_and_delete_pool	igroup follows its LUN maps	ONTAP removes the igroup on last unmap; leftovers legitimately keep it
test_16_create_vm_and_attach_volume	Competing-pool guard; libvirt domain, XML, device, session and igroup checks	Fail clearly on placement problems; verify the host
test_18_grow_and_shrink_pool_with_vm_attached	Verify the guest disk capacity as libvirt sees it during grow and shrink	The pool resize must reach the running VM
test_19_delete_volume_and_pool	Check this volume's own LUN is gone (60 s poll); verify domain and devices released; igroup follows LUN maps	The FlexVol also holds the template-cache LUN and the router's root disk, so "0 LUNs" could never hold

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)

Suite	Result
iSCSI pool lifecycle	21 / 21 passed
NFS3 pool lifecycle	21 / 21 passed
iSCSI pool with volumes, zone-scoped, volume lifecycle, VM workflow	passed in the full run (one skip: the target is already logged in on the host)
NFS3 pool with volumes, zone-scoped, VM workflow	passed in the full run

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?

[github-actions]

🔴 Test Coverage Grade: D — Marginal

Metric	Value
Line coverage	25.83%
Branch coverage	20.12%

Grade Scale

Grade	Line Coverage	Meaning
🟢 A	≥ 80%	Excellent - this code sleeps well at night 😴
🟡 B	60-79%	Good - almost there, don't stop now 😉
🟠 C	40-59%	Acceptable - your code is wearing a seatbelt, but no airbags 😬
🔴 D	20-39%	Marginal - boldly shipping where no test has gone before 🖖
⛔ F	< 20%	Failing - tests? what tests? 🔥

Branch coverage is shown as a secondary signal. Grade is determined by line coverage.
View full Actions run