CloudStack Volume support with ONTAP storage by rajiv-jain-netapp · Pull Request #13053 · apache/cloudstack

rajiv-jain-netapp · 2026-04-22T02:58:39Z

Description

Co-authored-by: Sandeep Locharla sandeep.locharla@netapp.com
Co-authored-by: Piyush Srivastava piyush5@netapp.com
Co-authored-by: Surya Gupta suryag@netapp.com

This PR...

Supports cloudstack-volume usecases support for NFS3 and iSCSI protocols.
Support for cloudStack-volume create/delete/attach/detach/snapshot-create.
Instance create/delete/snapshot-create support
Snapshot-create would not support
1. memory snapshot
2. user input for quicing option during snapshot creation

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

Screenshots (if appropriate):

How Has This Been Tested?

Testing Done:

VM create

Validate the respective CloudStack volume

Storage view for the cloudStack volumes

VM snapshot support

Storage view, post snapshot create

CloudStack UI list view for snapshot

CloudStack volume snapshot support

Storage view, post snapshot create

CloudStack UI list view for snapshot

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

… added EOF fixes

… added EOF fixes + correcting license header

Initial primary storage pool plugin skeleton

…POJOs" This reverts commit fe0f752.

…POJOs" This reverts commit 28faca1.

Feignconfiguration and volume feignClient along with desired POJOs with cstack 28

* CSTACKEX-29 Cluster, SVM and Aggr Feign Client * CSTACKEX-29 Change the endpoint method name in feign client * CSTACKEX-29 Make the alignment proper * CSTACKEX-29 Added License Info * CSTACKEX-29 Resolve Review Comments * CSTACKEX-29 Remove Component Annotation from datastoredriverclass * CSTACKEX-29 Resolve Style check issues * CSTACKEX-29 Resolve ALL Style issues * CSTACKEX-29 Resolve Precommits Issues * CSTACKEX-29 Added Method comments and change the ontap response class name --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

* CSTACKEX-31 NAS and Job Feign Client and POJOs * CSTACKEX-31 Fixed Checks Issues * CSTACKEX-31 Resolve Review Comments * CSTACKEX-31 Resolve Review Comments * CSTACKEX-31 Resolve Review Comments * CSTACKEX-31 Added Aggr and size to volume model * CSTACKEX-31 Change the export policy endpoint path * CSTACKEX-31 Fixed check styles --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

* CSTACKEX-30 SAN Feign Client * CSTACKEX-30 Fixed check style issues * CSTACKEX-30 Fixed review comments --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

* CSTACKEX-7: ONTAP Primary storage pool --------- Co-authored-by: Locharla, Sandeep <Sandeep.Locharla@netapp.com>

CSTACKEX-34: Upgrade to framework classes design

* CSTACKEX-35 Create Async * CSTACKEX-35 Added Null and empty check * CSTACKEX-35 Resolved review comments * CSTACKEX-35 Removed Type Casting for logger --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

* CSTACKEX-1: Feign changes and fixes for getting storage pool creation to work * CSTACKEX-01: Create Primary Storage pool changes with working code * CSTACKEX-01: Addressed all review comments and updated some code * CSTACKEX-01: Made some changes to fix some errors seen during testing * CSTACKEX-01: Addressed additional comments --------- Co-authored-by: Locharla, Sandeep <Sandeep.Locharla@netapp.com>

rajiv-jain-netapp · 2026-06-11T07:05:21Z

@nvazquez took care of your comments, please check and confirm further.

nvazquez

Thanks @rajiv-jain-netapp - code LGTM

rajiv-jain-netapp · 2026-06-12T12:02:39Z

Thanks @rajiv-jain-netapp - code LGTM

thank you @nvazquez

weizhouapache · 2026-06-12T12:50:53Z

        List<VolumeVO> volumes = volumeDao.findByInstance(vmId);
        for (VolumeVO volume : volumes) {
            StoragePoolVO storagePoolVO = storagePool.findById(volume.getPoolId());
+            if (storagePoolVO.isManaged() && DataStoreProvider.ONTAP_PLUGIN_NAME.equals(storagePoolVO.getStorageProviderName())) {


@rajiv-jain-netapp
This check is used in several places, so it would be good to extract it into a separate method.

I also noticed that NetworkFileSystem or Iscsi storage pools are created (#12563). However, as you've pointed out, CloudStack supports many operations on traditional NFS storage, and some of those operations are not supported by NetApp ONTAP.

Have you considered introducing a new storage pool type, for example NetAppNFS or NetAppIscsi ? That might make it easier to distinguish the capabilities and handle NetApp-specific behavior.

@rajiv-jain-netapp
I am not sure if you saw this comment

Hi @weizhouapache , we have it pipelined for this task of adding NetApp-specific protocols. IN the interest of deadlines for 4.23. We proceeded with default protocols.

ping @rajiv-jain-netapp

nvazquez · 2026-06-15T01:15:10Z

Thanks @rajiv-jain-netapp, in addition to this PR can you please raise a documentation PR to the repository https://github.com/apache/cloudstack-documentation?

ingox · 2026-06-15T14:31:20Z

Hi @rajiv-jain-netapp,

I'm interested in how this works.

What hypervisors are supported for iSCSI? KVM as well?

Is a separate volume being created for each disk in CloudStack?

Best regards,
Ingo

rajiv-jain-netapp · 2026-06-15T15:30:31Z

Hi @rajiv-jain-netapp,

I'm interested in how this works.

What hypervisors are supported for iSCSI? KVM as well?

Is a separate volume being created for each disk in CloudStack?

Best regards, Ingo

Hey @ingox , thanks for the comment.
What hypervisors are supported for iSCSI? KVM as well?
[Rajiv] yes KVM hypervisor would be enabled and supported with iSCSI.

Is a separate volume being created for each disk in CloudStack?
[Rajiv] For iSCSI, a LUN is created for each CloudStack volume (disk), whereas for NFS, the corresponding entity is created as a file. Based on customer feedback and beta validation, we plan to introduce additional flexibility to allow users to choose whether a dedicated storage volume should be provisioned for each CloudStack volume (disk).

ingox · 2026-06-16T06:49:37Z

Hi @rajiv-jain-netapp,
I'm interested in how this works.
What hypervisors are supported for iSCSI? KVM as well?
Is a separate volume being created for each disk in CloudStack?
Best regards, Ingo

Hey @ingox , thanks for the comment. What hypervisors are supported for iSCSI? KVM as well? [Rajiv] yes KVM hypervisor would be enabled and supported with iSCSI.

Is a separate volume being created for each disk in CloudStack? [Rajiv] For iSCSI, a LUN is created for each CloudStack volume (disk), whereas for NFS, the corresponding entity is created as a file. Based on customer feedback and beta validation, we plan to introduce additional flexibility to allow users to choose whether a dedicated storage volume should be provisioned for each CloudStack volume (disk).

@rajiv-jain-netapp thank you for your reply. How about DR and snap mirror functionality? Is it possible to group a number of disks to a protection group and mirror them to the DR side? Those disks can be all disks of a host or all the disks of all hosts which belong to one system (like App server, DB server, ...)

rajiv-jain-netapp · 2026-06-18T08:58:29Z

Update: We are working on documentation in parallel. Meanwhile, wanted to check in case any further comments for us to address for approval, followed by a merge.

nvazquez · 2026-06-23T11:28:19Z

Thanks @rajiv-jain-netapp so far there is only one pending review comment: #13053 (comment), can you please check it?

venkythegreat · 2026-06-25T16:47:57Z

Thanks @rajiv-jain-netapp so far there is only one pending review comment: #13053 (comment), can you please check it?

Rajiv responded to this above.. Apologies , it was in draft state and not committed.

weizhouapache · 2026-06-25T17:44:59Z

Hi @weizhouapache , we have it pipelined for this task of adding NetApp-specific protocols. IN the interest of deadlines for 4.23. We proceeded with default protocols.

thanks @rajiv-jain-netapp for the reply.

From a long-term maintenance perspective, I think introducing new storage pool types would be preferable. That said, I understand the time constraints for this release.

If you decide to keep the current implementation for now, I am fine with it. I do hope you can revisit and improve this in the next release.

cc @DaanHoogland @harikrishna-patnala

rajiv-jain-netapp · 2026-06-26T04:19:08Z

Hi @rajiv-jain-netapp,
I'm interested in how this works.
What hypervisors are supported for iSCSI? KVM as well?
Is a separate volume being created for each disk in CloudStack?
Best regards, Ingo

Hey @ingox , thanks for the comment. What hypervisors are supported for iSCSI? KVM as well? [Rajiv] yes KVM hypervisor would be enabled and supported with iSCSI.
Is a separate volume being created for each disk in CloudStack? [Rajiv] For iSCSI, a LUN is created for each CloudStack volume (disk), whereas for NFS, the corresponding entity is created as a file. Based on customer feedback and beta validation, we plan to introduce additional flexibility to allow users to choose whether a dedicated storage volume should be provisioned for each CloudStack volume (disk).

@rajiv-jain-netapp thank you for your reply. How about DR and snap mirror functionality? Is it possible to group a number of disks to a protection group and mirror them to the DR side? Those disks can be all disks of a host or all the disks of all hosts which belong to one system (like App server, DB server, ...)
@ingox Yes, I have one extension to the snapshot workflows to come soon, And this would seed the DR solutions in the subsequent releases.

rajiv-jain-netapp · 2026-06-26T04:57:26Z

Hi @weizhouapache , we have it pipelined for this task of adding NetApp-specific protocols. IN the interest of deadlines for 4.23. We proceeded with default protocols.

thanks @rajiv-jain-netapp for the reply.

From a long-term maintenance perspective, I think introducing new storage pool types would be preferable. That said, I understand the time constraints for this release.

If you decide to keep the current implementation for now, I am fine with it. I do hope you can revisit and improve this in the next release.

cc @DaanHoogland @harikrishna-patnala

yes @weizhouapache , we will add types and update all with the next set of features.

DaanHoogland · 2026-06-26T06:42:10Z

From a long-term maintenance perspective, I think introducing new storage pool types would be preferable. That said, I understand the time constraints for this release.

If you decide to keep the current implementation for now, I am fine with it. I do hope you can revisit and improve this in the next release.

cc @DaanHoogland @harikrishna-patnala

all good for my sake, @weizhouapache . cc @winterhazel

weizhouapache · 2026-06-26T10:36:34Z

@nvazquez @winterhazel
could you please check if your comments have been addressed ?

please let me know if this PR is good to you.

nvazquez · 2026-06-26T10:48:44Z

Yes @weizhouapache all good from my side, have previously approved: #13053 (review)

weizhouapache

code lgtm

winterhazel · 2026-06-29T03:04:17Z

@nvazquez @winterhazel could you please check if your comments have been addressed ?

please let me know if this PR is good to you.

The new changes look good to me, and the overall code as well. There's just a few comments that I think could still be addressed here.

#13053 (comment) - comment not matching the constant's value. It would be nice to confirm whether the constant's value is indeed the expected one and correct this comment if so.
#13053 (comment) - not sure if I was able to express myself correctly on this one, could you have another look @piyush5netapp? I was thinking about removing the volumeInfo = volFactory.getVolume(volumeInfo.getId(), primaryDataStore) from there by setting the details (in-memory) inside the plugin's grantAccess method to prevent some extra database calls.
#13053 (comment) - minor remark, no need to create a map here.
#13053 (comment) - minor remark, no need to create a map here.

piyush5netapp · 2026-06-29T06:37:56Z

@winterhazel Correct me if this is what you are trying to suggest as per my understanding on this comment #13053 (comment) - We are doing volumeInfo.get_iScsiName() in VolumeServiceImpl.createManagedVolumeCopyTemplateAsync whose value is set during OntapPrimaryDatastoreDriver.grantAccess from db. Instead of setting details.put(PrimaryDataStore.MANAGED_STORE_TARGET, managedStoreTarget) using that value, set the PrimaryDataStore.MANAGED_STORE_TARGET in OntapPrimaryDatastoreDriver.grantAccess itself. This will save one db call happening in VolumeServiceImpl.createManagedVolumeCopyTemplateAsync right ?

If yes, I had 2 reasons of not pursuing that-

Since the details is Map<String,String> and MANAGED_STORE_TARGET and other keys is specific(used by) by core code instead of vendor, vendor need not to remember the key (Also having key as String type can be error prone by vendors).
Existing code 1323-1330 also set the details here instead of any storage vendor setting those in either createAsync or grantAccess.

My understanding was that the vendor should be responsible for updating the right data in volume fields like iscsi_name, path , pool_type etc instead of setting key,value in details map which can be used by orchestrator code.

Let me know if I misunderstood something.

rajiv-jain-netapp · 2026-06-29T06:45:35Z

@nvazquez @winterhazel could you please check if your comments have been addressed ?
please let me know if this PR is good to you.

The new changes look good to me, and the overall code as well. There's just a few comments that I think could still be addressed here.

#13053 (comment) - comment not matching the constant's value. It would be nice to confirm whether the constant's value is indeed the expected one and correct this comment if so. #13053 (comment) - not sure if I was able to express myself correctly on this one, could you have another look @piyush5netapp? I was thinking about removing the volumeInfo = volFactory.getVolume(volumeInfo.getId(), primaryDataStore) from there by setting the details (in-memory) inside the plugin's grantAccess method to prevent some extra database calls. #13053 (comment) - minor remark, no need to create a map here. #13053 (comment) - minor remark, no need to create a map here.

We have responded to all the comments,
Note: we are planning to raise another PR by EOD today, mostly for fixes and extensions on snapshot workflows

winterhazel · 2026-06-29T13:42:23Z

We have responded to all the comments

Thanks, the map-related ones make sense, so I resolved them. Also, I have submitted a reply to #13053 (comment) if you could have a look.

@winterhazel Correct me if this is what you are trying to suggest as per my understanding on this comment #13053 (comment) - We are doing volumeInfo.get_iScsiName() in VolumeServiceImpl.createManagedVolumeCopyTemplateAsync whose value is set during OntapPrimaryDatastoreDriver.grantAccess from db. Instead of setting details.put(PrimaryDataStore.MANAGED_STORE_TARGET, managedStoreTarget) using that value, set the PrimaryDataStore.MANAGED_STORE_TARGET in OntapPrimaryDatastoreDriver.grantAccess itself. This will save one db call happening in VolumeServiceImpl.createManagedVolumeCopyTemplateAsync right ?

Right, this is what I suggested initially.

If yes, I had 2 reasons of not pursuing that-
1. Since the details is Map<String,String> and MANAGED_STORE_TARGET and other keys is specific(used by) by core code instead of vendor, vendor need not to remember the key (Also having key as String type can be error prone by vendors).

2. Existing code 1323-1330  also set the details here instead of any storage vendor setting those in either createAsync or grantAccess.
My understanding was that the vendor should be responsible for updating the right data in volume fields like iscsi_name, path , pool_type etc instead of setting key,value in details map which can be used by orchestrator code.

Your points make sense from an architectural view, but we've got an exception here anyways in which the core will need to perform an extra step for all providers to set this detail due to how a single vendor works.

Alternatively, can we move grantAccess(volumeInfo, destHost, primaryDataStore); to a line before Map<String, String> details = new HashMap<>(); and replace the current L1328 with L1346 then (also remove the current L1344-L1348)? This in-memory details is not used by any provider, only for the final CopyCommand. This way, we do not have to perform this extra step.

Jain, Rajiv and others added 30 commits October 3, 2025 14:02

Initial primary storage pool plugin skeleton

4c8c8d9

Initial primary storage pool plugin skeleton - added license string

bf838b3

Initial primary storage pool plugin skeleton - added license string +…

b82fb40

… added EOF fixes

Initial primary storage pool plugin skeleton - added license string +…

1199d55

… added EOF fixes + correcting license header

Merge pull request #1 from NetApp/feature-CSTACKEX-24

ebc3f00

Initial primary storage pool plugin skeleton

Feignconfiguration and volume feignClient along with desired POJOs

28faca1

Feignconfiguration and volume feignClient along with desired POJOs

fe0f752

Revert "Feignconfiguration and volume feignClient along with desired …

35f1011

…POJOs" This reverts commit fe0f752.

Revert "Feignconfiguration and volume feignClient along with desired …

a03a2c4

…POJOs" This reverts commit 28faca1.

Feignconfiguration and volume feignClient along with desired POJOs

2e0efe8

Feignconfiguration and volume feignClient along with desired POJOs

a96eb9e

CSTACKEX-28: added copyright comment in the logger configuration

0f09c5f

CSTACKEX-28: added newline in the end of the file

2cc4b0c

CSTACKEX-28 - incorporated review comments

033c23d

Merge pull request #4 from NetApp/feature/CSTACKEX-28

2822946

Feignconfiguration and volume feignClient along with desired POJOs with cstack 28

CSTACKEX-30 SAN Feign Client (#8)

a492797

* CSTACKEX-30 SAN Feign Client * CSTACKEX-30 Fixed check style issues * CSTACKEX-30 Fixed review comments --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

CSTACKEX-7: ONTAP Primary storage pool (#9)

25353c2

* CSTACKEX-7: ONTAP Primary storage pool --------- Co-authored-by: Locharla, Sandeep <Sandeep.Locharla@netapp.com>

CSTACKEX-34: Upgrade to framework classes design

973f5e2

CSTACKEX-34: incorporating the review comments

686a892

CSTACKEX-34: transient changes to the review comments

edfcdde

CSTACKEX-34: Unable to get checkstyle pass hence fixing this as well

73eb9f5

CSTACKEX-34: further review comments incorporations

465fffe

CSTACKEX-34: addressing checkstyle issues

3d6bd91

CSTACKEX-34: fix checksyle issues

5815ebd

Merge pull request #13 from NetApp/feature/CSTACKEX-34

618f957

CSTACKEX-34: Upgrade to framework classes design

CSTACKEX-35 Create Async (#14)

6c4b24e

* CSTACKEX-35 Create Async * CSTACKEX-35 Added Null and empty check * CSTACKEX-35 Resolved review comments * CSTACKEX-35 Removed Type Casting for logger --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

Merge branch 'apache:main' into main

54ddfa9

rajiv-jain-netapp added 3 commits June 11, 2026 12:00

CSTACKEX-191: adding null check for the lunResponse

a633c59

CSTACKEX-191: review comments incorporated

aaef6ff

CSTACKEX-191: addressing copilot comments

37924f0

github-actions Bot mentioned this pull request Jun 11, 2026

[repo-status] Daily Status Report — June 11, 2026 #13405

Closed

nvazquez approved these changes Jun 12, 2026

View reviewed changes

weizhouapache reviewed Jun 12, 2026

View reviewed changes

github-actions Bot mentioned this pull request Jun 12, 2026

[repo-status] Daily Status Report — June 12, 2026 #13413

Closed

github-actions Bot mentioned this pull request Jun 15, 2026

[repo-status] Daily Status Report — June 15, 2026 #13425

Closed

rajiv-jain-netapp closed this Jun 26, 2026

rajiv-jain-netapp reopened this Jun 26, 2026

weizhouapache approved these changes Jun 26, 2026

View reviewed changes

Uh oh!

Conversation

rajiv-jain-netapp commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

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

Uh oh!

rajiv-jain-netapp commented Jun 11, 2026

Uh oh!

nvazquez left a comment

Choose a reason for hiding this comment

Uh oh!

rajiv-jain-netapp commented Jun 12, 2026

Uh oh!

weizhouapache Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

weizhouapache Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

rajiv-jain-netapp Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

weizhouapache Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

nvazquez commented Jun 15, 2026

Uh oh!

ingox commented Jun 15, 2026

Uh oh!

rajiv-jain-netapp commented Jun 15, 2026

Uh oh!

ingox commented Jun 16, 2026

Uh oh!

rajiv-jain-netapp commented Jun 18, 2026

Uh oh!

nvazquez commented Jun 23, 2026

Uh oh!

venkythegreat commented Jun 25, 2026

Uh oh!

weizhouapache commented Jun 25, 2026

Uh oh!

rajiv-jain-netapp commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rajiv-jain-netapp commented Jun 26, 2026

Uh oh!

DaanHoogland commented Jun 26, 2026

Uh oh!

weizhouapache commented Jun 26, 2026

Uh oh!

nvazquez commented Jun 26, 2026

Uh oh!

weizhouapache left a comment

Choose a reason for hiding this comment

Uh oh!

winterhazel commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

piyush5netapp commented Jun 29, 2026

Uh oh!

rajiv-jain-netapp commented Jun 29, 2026

Uh oh!

winterhazel commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

rajiv-jain-netapp commented Apr 22, 2026 •

edited

Loading

rajiv-jain-netapp commented Jun 26, 2026 •

edited

Loading

winterhazel commented Jun 29, 2026 •

edited

Loading