Repository navigation
CSTACKEX-127: Primary storage-pool is getting created even if desired data LIFs are not reachable - #76
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the ONTAP primary storage workflow to select a reachable/usable data LIF based on operational status and node affinity (aggregate home node vs. failover vs. cross-node fallback), and surfaces warnings via pool details/alerts when selection is degraded.
Changes:
- Adds node-aware, status-aware LIF selection in
StorageStrategy.getNetworkInterface()and returns both the chosen LIF IP + an optional warning. - Captures the chosen aggregate’s node during volume creation to bias LIF selection toward optimal locality.
- Updates lifecycle + tests to handle the new
(lifIp, warning)result and emits storage alerts when degraded selection occurs.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| plugins/storage/volume/ontap/src/test/java/org/apache/cloudstack/storage/service/StorageStrategyTest.java | Expands unit tests for LIF status and node-affinity tiers; avoids mocking issues on newer JDKs. |
| plugins/storage/volume/ontap/src/test/java/org/apache/cloudstack/storage/lifecycle/OntapPrimaryDatastoreLifecycleTest.java | Updates mocks for new Pair<String,String> LIF return type and scope behavior. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/utils/OntapStorageUtils.java | Adds helper to send storage alerts for degraded LIF selection. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/utils/OntapStorageConstants.java | Adds constants for aggregate node/space fields and LIF state/location/warning keys. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/StorageStrategy.java | Implements tiered LIF selection and tracks chosenAggregateNode from aggregate selection. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/lifecycle/OntapPrimaryDatastoreLifecycle.java | Persists selected LIF + warning and emits an alert during pool initialization. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/feign/model/IpInterface.java | Extends model with state, enabled, and location to support selection logic. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/feign/model/Aggregate.java | Extends model with node and setters needed for reading/constructing detailed aggregate info. |
| plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/feign/client/AggregateFeignClient.java | Adds @QueryMap to request specific aggregate fields (node/space/state). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
2b19269 to
50d9045
Compare
50d9045 to
52fc886
Compare
52fc886 to
7d0f4c4
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (3)
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/lifecycle/OntapPrimaryDatastoreLifecycle.java:169
- If Data LIF selection fails after createStorageVolume() succeeds, initialize() throws and can leave an orphaned ONTAP volume on the array. Add best-effort cleanup (deleteStorageVolume) when getNetworkInterface()/processDataLifSelection fails so failed pool creation doesn’t leak storage resources.
logger.info("Creating ONTAP volume '" + storagePoolName + "' with size: " + capacityBytes + " bytes (" +
(capacityBytes / (1024 * 1024 * 1024)) + " GB)");
try {
Volume volume = storageStrategy.createStorageVolume(storagePoolName, capacityBytes);
if (volume == null) {
logger.error("createStorageVolume returned null for volume: " + storagePoolName);
throw new CloudRuntimeException("Failed to create ONTAP volume: " + storagePoolName);
}
logger.info("Volume object retrieved successfully. UUID: " + volume.getUuid() + ", Name: " + volume.getName());
details.putIfAbsent(OntapStorageConstants.VOLUME_UUID, volume.getUuid());
details.putIfAbsent(OntapStorageConstants.VOLUME_NAME, volume.getName());
} catch (Exception e) {
logger.error("Exception occurred while creating ONTAP volume: " + storagePoolName, e);
throw new CloudRuntimeException("Failed to create ONTAP volume: " + storagePoolName + ". Error: " + e.getMessage(), e);
}
Pair<String, String> lifResult;
try {
lifResult = storageStrategy.getNetworkInterface();
} catch (Exception e) {
logger.error("Exception occurred while retrieving network interface for pool: " + storagePoolName, e);
throw new CloudRuntimeException("Failed to retrieve Data LIF from ONTAP: " + e.getMessage(), e);
}
processDataLifSelection(lifResult, details, storagePoolName, zoneId, podId);
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/StorageStrategy.java:532
- getNetworkInterface() dereferences iface.getIp().getAddress() without checking iface.getIp() (or address) for null. If ONTAP returns a LIF record missing the nested ip object/address, this will throw a NullPointerException and mask the real selection failure.
for (IpInterface iface : response.getRecords()) {
if (!Boolean.TRUE.equals(iface.getEnabled()) || !OntapStorageConstants.LIF_STATE_UP.equals(iface.getState())) {
continue;
}
if (!isIPv4Address(iface.getIp().getAddress())) {
continue;
}
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/StorageStrategy.java:213
- validateAndSelectAggregatesForVolumeCreation() overwrites this.aggregates on every eligible aggregate and ends up keeping only the last one. Since createStorageVolume() later chooses the ‘best’ aggregate only from this.aggregates, this can cause the plugin to ignore higher-free-space aggregates depending on ONTAP response order.
private void validateAndSelectAggregatesForVolumeCreation(String authHeader, String svmName, List<Aggregate> aggrs) {
if (aggrs == null || aggrs.isEmpty()) {
logger.error("No aggregates are assigned to SVM " + svmName);
throw new CloudRuntimeException("No aggregates are assigned to SVM " + svmName);
}
for (Aggregate aggr : aggrs) {
logger.debug("Found aggregate: " + aggr.getName() + " with UUID: " + aggr.getUuid());
Aggregate aggrResp = aggregateFeignClient.getAggregateByUUID(authHeader, aggr.getUuid(),
Map.of(OntapStorageConstants.FIELDS, OntapStorageConstants.AGGREGATE_NODE
+ OntapStorageConstants.COMMA + OntapStorageConstants.AGGREGATE_SPACE
+ OntapStorageConstants.COMMA + OntapStorageConstants.STATE));
if (aggrResp == null) {
logger.warn("Aggregate details response is null for aggregate " + aggr.getName() + ". Skipping.");
continue;
}
if (!Objects.equals(aggrResp.getState(), Aggregate.StateEnum.ONLINE)) {
logger.warn("Aggregate " + aggr.getName() + " is not in online state. Skipping this aggregate.");
continue;
} else if (aggrResp.getSpace() == null || aggrResp.getAvailableBlockStorageSpace() == null ||
aggrResp.getAvailableBlockStorageSpace() <= storage.getSize().doubleValue()) {
logger.warn("Aggregate " + aggr.getName() + " does not have sufficient available space. Skipping this aggregate.");
continue;
}
logger.info("Selected aggregate: " + aggr.getName() + " for volume operations.");
this.aggregates = List.of(aggr);
}
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (4)
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/StorageStrategy.java:530
- getNetworkInterface() dereferences
iface.getIp().getAddress()without checkingiface.getIp()/ address for null, which can throw an NPE if ONTAP returns a LIF record missing the nestedipobject/address (partial/invalid responses).
for (IpInterface iface : response.getRecords()) {
if (!Boolean.TRUE.equals(iface.getEnabled()) || !OntapStorageConstants.LIF_STATE_UP.equals(iface.getState())) {
continue;
}
if (!isIPv4Address(iface.getIp().getAddress())) {
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/lifecycle/OntapPrimaryDatastoreLifecycle.java:166
- If Data LIF selection/validation fails after createStorageVolume() succeeds, initialize() throws and can leave an orphaned volume on the array. Add best-effort cleanup (delete the created volume) on LIF selection/processing failure to avoid leaking storage resources on failed pool creation.
Pair<String, String> lifResult;
try {
lifResult = storageStrategy.getNetworkInterface();
} catch (Exception e) {
logger.error("Exception occurred while retrieving network interface for pool: " + storagePoolName, e);
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/StorageStrategy.java:213
- validateAndSelectAggregatesForVolumeCreation() keeps iterating after selecting a suitable aggregate, overwriting
this.aggregateseach time. This makes the chosen aggregate depend on iteration order (last suitable wins) and triggers unnecessary extra ONTAP API calls.
logger.info("Selected aggregate: " + aggr.getName() + " for volume operations.");
this.aggregates = List.of(aggr);
}
plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/listener/OntapHostListener.java:181
- updateNfsExportPolicyForConnectedHostIfNeeded() no longer distinguishes between a missing host and a host that isn't eligible for NFS3: when
hostis null,isNfs3EnabledOnHost(host)returns false and the code throws "NFS protocol is not enabled...", which is misleading compared to the previous explicit "Host was not found" error.
if (!isNfs3EnabledOnHost(host)) {
throw new CloudRuntimeException("NFS protocol is not enabled on host with id: " + hostId);
| @@ -200,7 +210,6 @@ private void validateAndSelectAggregatesForVolumeCreation(String authHeader, Str | |||
| } | |||
| logger.info("Selected aggregate: " + aggr.getName() + " for volume operations."); | |||
| this.aggregates = List.of(aggr); | |||
There was a problem hiding this comment.
Refactor the code and modularize aggregate selection, volume creation and fetching network interfaces. Raise a PR for this.
|
|
||
| @JsonIgnoreProperties(ignoreUnknown = true) | ||
| @JsonInclude(JsonInclude.Include.NON_NULL) | ||
| public static class Node { |
There was a problem hiding this comment.
if the aggregate also has same static inner class Node, lets have a separate Node model
| if (iface.getIp().getAddress().contains(".")) { | ||
| ipInterface = iface; | ||
| break; | ||
| if (response == null || response.getRecords() == null || response.getRecords().isEmpty()) { |
There was a problem hiding this comment.
we can use CollectionsUtil.isEmpty() on records
rajiv-jain-netapp
left a comment
There was a problem hiding this comment.
As discussed, we will be picking up the review comments in the separate PR, with this approving this PR.
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" />
… ONTAP storage plugin (apache#13897) * Multi-Host support for NFS3 and iSCSI(Addition/Removal of host) (#64) This PR provides support to addition and removal of multiple hosts to NFS3 and iSCSI type storage pools <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] 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) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [ ] Major - [ ] Minor - [ ] Trivial **Only 1 Host present in the Cluster** <img width="1049" height="340" alt="Screenshot 2026-07-14 at 9 19 49 AM" src="https://github.com/user-attachments/assets/8d639c94-6686-40de-a362-341d41ff48fe" /> **Created an NFS3 StoragePool with Cluster scope** <img width="1049" height="340" alt="Screenshot 2026-07-14 at 9 20 58 AM" src="https://github.com/user-attachments/assets/f14cc903-bd60-47d4-8a7c-5a2ec4d2e0d0" /> **ONTAP volume created for the SP** <img width="1101" height="305" alt="Screenshot 2026-07-14 at 9 21 30 AM" src="https://github.com/user-attachments/assets/7823e398-782d-472d-948d-25153d5c372a" /> **Export Policy rule and client** <img width="1077" height="407" alt="Screenshot 2026-07-14 at 9 34 00 AM" src="https://github.com/user-attachments/assets/5426f9d4-cc96-45dc-9857-0312227867c8" /> **Added a new host** <img width="1048" height="314" alt="Screenshot 2026-07-14 at 9 24 42 AM" src="https://github.com/user-attachments/assets/5acd2a38-6b54-4393-a4f9-86790f1c81de" /> **Updated client in the Export Policy** <img width="1077" height="407" alt="Screenshot 2026-07-14 at 9 35 24 AM" src="https://github.com/user-attachments/assets/7d0e8470-3391-4909-9de9-a3f22fead439" /> **Removed the host from the cluster** <img width="1042" height="342" alt="Screenshot 2026-07-14 at 9 32 16 AM" src="https://github.com/user-attachments/assets/24fea619-4c8b-4805-ad53-49fc2fb6aa13" /> **The respective client has been removed from the Export Policy** <img width="1077" height="423" alt="Screenshot 2026-07-14 at 9 36 07 AM" src="https://github.com/user-attachments/assets/76e62a97-a034-4c75-8642-41bd116938e1" /> Test Done | Result | Comments -- | -- | -- Create an instance by specifying the host and disk offering pointed to NFS3 Primary Storage Pool (Cluster scoped with min of 2 hosts) | PASS | Create an instance specifying host and disk offering pointed to iSCSI Primary Storage Pool (Cluster scoped with min of 2 hosts) | PASS | Create an instance in a cluster with atleast 2 hosts in the cluster by not specifying the host and disk offering pointed to NFS3 Primary Storage Pool (Cluster scoped with min of 2 hosts) | PASS | Create an instance in a cluster with atleast 2 hosts in the cluster by not specifying the host and disk offering pointed to iSCSI Primary Storage Pool (Cluster scoped with min of 2 hosts) | PASS | Create an instance by specifying the host and disk offering pointed to 2 NFS3 Primary Storage Pools (Cluster scoped + Zone scoped) | FAIL | StoragePoolAllocator is coming as empty and the random strategy to allocate was failing. Create an instance by specifying the host and disk offering pointed to 2 iSCSI Primary Storage Pools (Cluster scoped + Zone scoped) | FAIL | StoragePoolAllocator is coming as empty and the random strategy to allocate was failing. Create an instance by specifying the host and disk offering pointed to NFS3 Primary Storage Pool (Zone scoped with min of 2 hosts) | FAIL | Zone scoped instance creation failing (CSTACKEX-188) Create an instance specifying host and disk offering pointed to iSCSI Primary Storage Pool (Zone scoped with min of 2 hosts) | FAIL | Zone scoped instance creation failing (CSTACKEX-188) Create an instance in a cluster with atleast 2 hosts in the cluster by not specifying the host and disk offering pointed to NFS3 Primary Storage Pool (Zone scoped with min of 2 hosts) | FAIL | Zone scoped instance creation failing (CSTACKEX-188) Create an instance in a cluster with atleast 2 hosts in the cluster by not specifying the host and disk offering pointed to iSCSI Primary Storage Pool (Zone scoped with min of 2 hosts) | FAIL | Zone scoped instance creation failing (CSTACKEX-188) Power off VM on Host-1 and start it on Host-2 (same cluster) with disk offering pointed to NFS3 primary storage pool (cluster scoped) | PASS | Power off and on a VM with 'last known host' selected. Create the instance in a cluster, without specifying a host. | PASS | Last known host was selected Power off and on a VM with 'last known host' NOT selected. Create the instance in a cluster, without specifying a host. | PASS | VM got hosted on the chosen host. Power off and on a VM with 'last known host' selected but choose a different host. Create the instance in a cluster, without specifying a host. | PASS | VM got hosted on the chosen host. Insufficient resources in the storage pool. Instance creation should fail. | PASS | Generic error is being displayed instead of proper error regarding Insufficient resources. One host in the cluster (min. 2 hosts) loaded, resulting in insufficient CPU. Disk Offering pointed to Cluster scoped primary storage pool. | PASS | Both host in the cluster (min. 2 hosts) loaded, resulting in insufficient CPU. Disk Offering pointed to Cluster scoped primary storage pool. Instance creation should fail but disks should first get created and then destroyed. * Fix for NFS3 primary storage pool is failing to come out of maintenan… (#71) Fix for NFS3 primary storage pool is failing to come out of maintenance mode ### Description This PR has the following: 1. For NetworkFileSystem type, libvirtd handles mounting and unmounting of nfs mount [Ref: https://libvirt.org/storage.html] 2. KVM adaptor hasn't overridden `deleteStoragePool` method leading to only just the change in the DB. This was leading to error in case of `Cancel Maintenance` as the pool already exists with the host. 3. Also, when `Enable Maintenance` call comes, it was first removing the nfs mount, which was causing the libvirtd to error out during `Destroy Pool` call as the mount wasn't available. <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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 - [X] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? `Previously:` <img width="1035" height="362" alt="Screenshot 2026-07-08 at 8 00 05 AM" src="https://github.com/user-attachments/assets/91a3bcd7-cb6f-4b53-81f5-0851abd337ee" /> <img width="1301" height="365" alt="Screenshot 2026-07-08 at 7 58 31 AM" src="https://github.com/user-attachments/assets/5444b1ae-5cfa-4709-a48f-107b8a257e29" /> <img width="1035" height="362" alt="Screenshot 2026-07-08 at 8 00 29 AM" src="https://github.com/user-attachments/assets/bbeaece1-8795-46ef-b1c7-9a9b24910b21" /> <img width="1301" height="327" alt="Screenshot 2026-07-08 at 8 01 37 AM" src="https://github.com/user-attachments/assets/c9086ef2-066c-4661-a684-c4788e471fdc" /> So, clearly though the nfs mount was removed, the libvirtd still has the pool details with it. `Now:` <img width="1042" height="351" alt="Screenshot 2026-07-08 at 8 30 46 AM" src="https://github.com/user-attachments/assets/59d2c629-41bd-4991-9988-3989dd3497aa" /> <img width="1300" height="382" alt="Screenshot 2026-07-08 at 8 31 18 AM" src="https://github.com/user-attachments/assets/9b774243-8329-4fb8-babb-a0891d20fc6a" /> <img width="1043" height="355" alt="Screenshot 2026-07-08 at 8 32 41 AM" src="https://github.com/user-attachments/assets/5207517a-c2d0-4935-adf0-db70877b79fa" /> <img width="1299" height="312" alt="Screenshot 2026-07-08 at 8 33 02 AM" src="https://github.com/user-attachments/assets/fd5014bb-8d46-423b-8039-b2caa391b885" /> <img width="1049" height="340" alt="Screenshot 2026-07-08 at 8 34 32 AM" src="https://github.com/user-attachments/assets/ec951783-a90e-4118-89d2-8d62b28f138e" /> <img width="1299" height="365" alt="Screenshot 2026-07-08 at 8 33 46 AM" src="https://github.com/user-attachments/assets/a64a2c86-9089-4f67-a345-90a0dbfa88fc" /> * Fixes to handle 404 exceptions when export policy and ontap volume ar… (#73) Fixes to handle 404 exceptions when export policy and ontap volume are missing during storagepool delete workflow This PR... Has fixes to handle 404 Not found exceptions in case of 'ExportPolicy' and 'Volume' deletion. **latest** <img width="1301" height="503" alt="Screenshot 2026-08-02 at 2 13 22 PM" src="https://github.com/user-attachments/assets/53e48052-c833-4758-acff-b6ee753113cf" /> <img width="1293" height="674" alt="Screenshot 2026-07-01 at 3 13 00 PM" src="https://github.com/user-attachments/assets/46190b26-500c-448b-b65e-4b989e8dca28" /> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [ ] Major - [] Minor - [ ] BLOCKER - [ ] Critical - [ ] Major - [X] Minor - [ ] Trivial <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * create temp CG for consistent VM snapshot for the VM which is span across multiple flexvolumes (#74) This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] 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) - [x] 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) - [x] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [x] Major - [ ] Minor - [ ] Trivial <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * CSTACKEX-127: Primary storage-pool is getting created even if desired data LIFs are not reachable (#76) Choosing IpInterface based on its status and affinity to the chosen aggregate This PR... 1. Fixed an issue in picking an unavailable IP while creating the storage pool. 2. When CloudStack creates an ONTAP primary storage pool, it now picks the best available network interface (LIF) using a priority-based selection: - Best case: Uses a LIF homed on the same node as the storage aggregate — optimal I/O, no warning - Degraded case: All home-node LIFs are down but a failover LIF is running on that node — pool is created, admin is warned - Fallback case: No LIF at all on the aggregate's node, pool is created using a LIF from a different node, admin is warned with a latency note - Failure case: No usable LIF anywhere, pool creation fails with a clear error <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [X] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial Note: The following images have been captured for NFS3, the same would be the case for iSCSI. <img width="487" height="661" alt="Screenshot 2026-07-08 at 6 55 32 AM" src="https://github.com/user-attachments/assets/e48a42c7-9914-4563-bc27-f1ad6501629c" /> Clearly, by the virtue of free space available, the plugin would choose `sti246_vsim_ocvs040d_aggr1` by default. **Scenario-1 [pool_P1]: Happy path; No LIFs were down.** <img width="1122" height="742" alt="Screenshot 2026-07-07 at 10 26 34 PM" src="https://github.com/user-attachments/assets/8b748425-c548-4d03-8265-2b86a568f45b" /> <img width="1122" height="419" alt="Screenshot 2026-07-07 at 10 26 49 PM" src="https://github.com/user-attachments/assets/45177fc2-4e87-4ead-928e-659e50504d9d" /> <img width="1032" height="432" alt="Screenshot 2026-07-07 at 10 27 48 PM" src="https://github.com/user-attachments/assets/6bbe3533-2081-429d-ba1f-fa1a8731dd3f" /> The first best available LIF with current node and home node matching with the chosen node has been picked. **Scenario-2 [pool_P2_1]: LIFs on `040d` node were down; with one LIF whose current node: `040d`, while its home node: `040c`** <img width="1032" height="765" alt="Screenshot 2026-07-07 at 10 28 38 PM" src="https://github.com/user-attachments/assets/adb8e4ff-670b-49d2-b8ca-1d7558f34643" /> <img width="1032" height="415" alt="Screenshot 2026-07-07 at 10 28 50 PM" src="https://github.com/user-attachments/assets/6d982076-adba-4458-960b-dc0066d1c5a6" /> <img width="1032" height="380" alt="Screenshot 2026-07-07 at 11 05 22 PM" src="https://github.com/user-attachments/assets/c73957ec-a82b-4093-bf88-43da515d8663" /> <img width="1032" height="220" alt="Screenshot 2026-07-07 at 11 05 43 PM" src="https://github.com/user-attachments/assets/f179e0b7-808f-4643-9d89-7ebb52fa1d33" /> **Scenario-3 [pool_P3]: None of the `040d` node LIFs are UP. First best available LIF is picked from `040c`.** <img width="867" height="764" alt="Screenshot 2026-07-07 at 11 07 00 PM" src="https://github.com/user-attachments/assets/59a05c54-e4f7-468a-9682-9fc392ba45c9" /> <img width="867" height="420" alt="Screenshot 2026-07-07 at 11 07 22 PM" src="https://github.com/user-attachments/assets/87c4a008-17d8-4bff-9335-14e0707f9ddd" /> <img width="1029" height="425" alt="Screenshot 2026-07-07 at 11 08 30 PM" src="https://github.com/user-attachments/assets/2f2888d0-0a7a-4e29-91d4-d03f1bf4440e" /> <img width="1029" height="228" alt="Screenshot 2026-07-07 at 11 08 54 PM" src="https://github.com/user-attachments/assets/5cf00e5f-0a46-4010-899d-14c605b676d2" /> * CSTACKEX-212: fix for snapshot failure for attached cs volumes nfs an… (#77) ### Description Fix snapshot failure for CloudStack volumes attached to running VMs on ONTAP primary storage (both NFS3 and iSCSI protocols). This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> When a volume was created and attached to a running VM in a single step,by enabling create on storage and choose the storage pool tag the volume format was not being set correctly. The format is now determined by the hypervisor type (KVM → QCOW2) in ontapdriver via [getImageFormatByHypervisor(HypervisorType] mirroring the [getSupportedImageFormatForCluster] in VolumeOrchestrator file. <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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 - [X] Major - [ ] Minor - [ ] Trivial ### How Has This Been Tested? Tested on a dev setup against these scenarios: Scenario A — Attach data disk to running VM, then snapshot - Create ONTAP primary storage pool (NFS3 or iSCSI) - Deploy VM with data disk using pool-tagged disk offering → VM reaches Running state - Create volume attached to the running VM by enabling create on storage and choose the storage pool tag - Take snapshot of attached volume — ✅ succeeds (was failing before fix) Scenario B — Attach volume to root-disk-only VM, then snapshot - Create ONTAP primary storage pool (NFS3 or iSCSI) - Deploy VM without data disk → VM reaches Running state - Create and attach volume to the running VM by enabling create on storage and choose the storage pool tag - Take snapshot of attached volume — ✅ succeeds (was failing before fix) scenarios-C-create a volume on storage pool but not attach to any vm - Create ONTAP primary storage pool (NFS3 or iSCSI) - Create volume by enabling create on storage and choose the storage pool tag - Take snapshot- — ✅ succeeds (was failing before fix) ### Screenshots (if appropriate): snapshots for when cs volume is attached to NFS and ISCSI instance that has both root and data disk and create on storage enabled: <img width="1464" height="436" alt="Screenshot 2026-07-15 at 12 28 32 AM" src="https://github.com/user-attachments/assets/69827e56-ac5d-4746-a2e9-f32ac8e95433" /> <img width="1472" height="414" alt="Screenshot 2026-07-15 at 12 28 38 AM" src="https://github.com/user-attachments/assets/799c8485-7023-4b1f-9eeb-3d0c4a745a57" /> verifying on ontap and db: <img width="1549" height="343" alt="Screenshot 2026-07-15 at 12 28 58 AM" src="https://github.com/user-attachments/assets/ee62e8b1-81a9-41b9-b5fb-639133a1cfff" /> <img width="1548" height="397" alt="Screenshot 2026-07-15 at 12 29 10 AM" src="https://github.com/user-attachments/assets/8f74ae08-437e-4ac6-aa24-49ef4675cd30" /> <img width="1720" height="175" alt="Screenshot 2026-07-15 at 12 30 43 AM" src="https://github.com/user-attachments/assets/088fbc14-581e-4ac9-85df-77bced054e3f" /> snapshots for when cs volume is attached to NFS and ISCSI instance that has only root and also case when they are not attached to any instance and create on storage enabled: <img width="1458" height="320" alt="Screenshot 2026-07-15 at 12 52 30 AM" src="https://github.com/user-attachments/assets/8150b81c-bc07-48e7-91ca-c93ef53b6e8a" /> <img width="1454" height="256" alt="Screenshot 2026-07-15 at 12 52 39 AM" src="https://github.com/user-attachments/assets/0408156a-6374-4026-b5aa-b51b070fd44f" /> <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * CSTACKEX-158: if ontap snapshot are already delete from ontap side, d… (#82) …Deletion of CS side of snapshot should not fail on not finding ontap snapshot. This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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) - [ ] Major - [x] Minor - [ ] BLOCKER - [ ] Critical - [ ] Major - [x] Minor - [ ] Trivial Test -1: Ran VM snapshot delete operation when the respective snapshot is not available at ONTAP, it passed. Test -2: Ran VM snapshot delete operation when the respective snapshot is available at ONTAP; it passed Test -3: Ran cloudstack volume snapshot delete workflow when the respective snapshot is not available at ONTAP, it passed. Test -4: Ran cloudstack volume snapshot delete workflow when the respective snapshot is available at ONTAP, it passed. <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * Resolved a merge conflict * Subsequent VM Creation is failing for ISCSI Storage Pool on Oracle Linux (#88) ### Description Subsequent VM Creation is failing for ISCSI Storage Pool on Oracle Linux <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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 - [x] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? Tested on both Oracle and Unbuntu and tried creating multiple VMs #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com> * Bugfix/CSTACKEX-254: Change the minimum storagepool size to 20MB and throw an exception in case of invalid capacity bytes instead of adjusting to minimum requirement (#94) This PR corrects the minimum allowed storage pool size from 1.56GB to 20MB as per ONTAP guidelines for FlexVol. Also, this removes the behaviour to silently correct the invalid capacity bytes to min. requirement, instead it'll throw an exception to let the user decide on the corrective action. <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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) - [ ] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial `Case-1: Storage Pool Capacity Bytes = 214B, less than the min. req of 20MB` <img width="1047" height="735" alt="Screenshot 2026-08-20 at 7 08 03 AM" src="https://github.com/user-attachments/assets/f09d23d8-4c74-4222-8b2e-e4b37b3de1b3" /> `Case-2: Storage Pool Capacity Bytes = 20971520B or 20MB` <img width="1047" height="735" alt="Screenshot 2026-08-20 at 7 15 58 AM" src="https://github.com/user-attachments/assets/8b4a47af-0d90-4636-bb48-5d41260a0fad" /> <img width="1047" height="735" alt="Screenshot 2026-08-20 at 7 16 27 AM" src="https://github.com/user-attachments/assets/f0033b69-0390-4fc6-8394-0e67247274be" /> <img width="1103" height="437" alt="Screenshot 2026-08-20 at 7 17 16 AM" src="https://github.com/user-attachments/assets/1bf51bd5-d746-43b6-b99e-fd87515db411" /> * CSTACKEX-241: adding in the updatestoragepool call of provider's lifecycle (#90) ### Description While implementing storage pool resize via the updateStoragePool API, StorageManagerImpl.updateStoragePool()updates the database but never calls PrimaryDataStoreLifeCycle.updateStoragePool() on the storage plugin. adding that call in here. This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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 - [x] Critical - [ ] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * bugfix/CSTACKEX-235: Updated job timing to be uniform across ONTAP (#93) ### Description This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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? <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> --------- Co-authored-by: Srivastava, Piyush <Piyush.Srivastava@netapp.com> * fixed a rebase error * CSTACKEX-246: setting volume format based on protocol (#92) ### Description OntapPrimaryDatastoreDriver now returns RAW format for KVM+iSCSI (was always QCOW2), and VolumeServiceImpl.managedCopyBaseImageCallback adds a volume.getFormat() != null guard to prevent the template's format from overwriting it. <img width="836" height="1614" alt="image" src="https://github.com/user-attachments/assets/f74184e8-82d8-4382-894f-e7fa7ad6ea57" /> This PR... <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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 - [x] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): <img width="1704" height="200" alt="Screenshot 2026-08-13 at 11 48 46 AM" src="https://github.com/user-attachments/assets/21de01f3-8ed4-4485-9b23-65d310e69440" /> ### How Has This Been Tested? Ran Iscsi automation suite: Everything is green <img width="2100" height="1520" alt="image" src="https://github.com/user-attachments/assets/bcb44bad-ce86-480c-9274-4f128817affa" /> <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * Addressed a rebase issue * Addressed review comments * Reuse the shared ONTAP snapshot delete during VM snapshot rollback so cleanup follows the normal delete path. (#127) ### Description This PR is to address a comment received on apache#13897 . `rollbackFlexVolSnapshot` now uses `deleteFlexVolSnapshotForCloudStackVolume` instead of issuing its own snapshot delete. <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [X] 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 - [X] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> #### How did you try to break this feature and the system with this change? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> * Addressed the comments received on upstream PR for refactoring the fix for NFS Cancel maintenance (#131) ### Description This PR addresses the comments received on upstream PR apache#13897 to refactor the code written for fixing the Cancel Maintenance where the Pool wasn't getting mounted back in case of NFS. <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] 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 - [X] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): <img width="1045" height="339" alt="Screenshot 2026-10-22 at 8 08 49 PM" src="https://github.com/user-attachments/assets/438b7f0e-8b45-4b39-a425-3fb4bd4451ab" /> <img width="1298" height="183" alt="Screenshot 2026-10-22 at 8 10 22 PM" src="https://github.com/user-attachments/assets/58507563-828d-4ff2-b50c-0decd4674578" /> <img width="1049" height="358" alt="Screenshot 2026-10-22 at 8 11 18 PM" src="https://github.com/user-attachments/assets/0ad746fd-137a-4e76-92c8-8bddf3d28692" /> <img width="1302" height="216" alt="Screenshot 2026-10-22 at 8 12 02 PM" src="https://github.com/user-attachments/assets/c0efeadf-a2b6-4328-adb3-928f6bfee618" /> <img width="1048" height="360" alt="Screenshot 2026-10-22 at 8 13 28 PM" src="https://github.com/user-attachments/assets/f6eae7fb-08fc-4d29-94b6-678371f0054c" /> <img width="1301" height="314" alt="Screenshot 2026-10-22 at 8 12 51 PM" src="https://github.com/user-attachments/assets/0eeba7e2-2e98-4e9c-b463-5606f1838776" /> ### How Has This Been Tested? - Created `Primary1` storage pool of `NetworkFileSystem` type using `DefaultPrimary` storage plugin. - Created `testPool` storage pool of `NetworkFileSystem` type using `NetApp ONTAP` storage plugin. - Enter Maintenance on both the pools. - Cancel Maintenance on both the pools. - At each stage, both `mount | grep nfs` and libvirtd's `virst pool-list --all` should reflect the pools appropriately. - Before Enter Maintenance, both the commands should have mount and pool listed respectively. - On Enter Maintenance, neither should be listed. - On Cancel Maintenance, both should be listed again. * let libvirt unmount NFS pools in the no details delete path * invoke lifecycle only on real changes and keep its details * pass a pool with the new capacity values to the lifecycle update hook --------- Co-authored-by: Rajiv Jain <rajiv1@netapp.com> Co-authored-by: Sathvika <sr73318@netapp.com> Co-authored-by: Surya Gupta <suryag@netapp.com> Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com> Co-authored-by: piyush5netapp <91685498+piyush5netapp@users.noreply.github.com> Co-authored-by: Srivastava, Piyush <Piyush.Srivastava@netapp.com> Co-authored-by: Fabricio Duarte <fabricio@apache.org>
Choosing IpInterface based on its status and affinity to the chosen aggregate
Description
This PR...
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Note: The following images have been captured for NFS3, the same would be the case for iSCSI.
Clearly, by the virtue of free space available, the plugin would choose
sti246_vsim_ocvs040d_aggr1by default.Scenario-1 [pool_P1]: Happy path; No LIFs were down.



The first best available LIF with current node and home node matching with the chosen node has been picked.
Scenario-2 [pool_P2_1]: LIFs on




040dnode were down; with one LIF whose current node:040d, while its home node:040cScenario-3 [pool_P3]: None of the




040dnode LIFs are UP. First best available LIF is picked from040c.