Change clone strategy to avoid PowerStore snapshot limits

[coulof]

What this PR does / why we need it:
PowerStore has a limit of 32 to 64 writable snapshots which prevents to create more VMs from a base OS.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Release note:

* Dell PowerStore uses `cloneStrategy: copy` over `csi-clone` to avoid array snapshot limits

[kubevirt-bot]

Hi @coulof. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[akalenyu]

So CSI/snapshot clones normally create ephemeral snapshots, which should keep us within limits.
Could you please attach some PowerStore source? I am probably misunderstanding the issue.

I want to ensure I poke at this a bit, since doing host assisted clones all over is going to be a major hit for anyone who uses this solution.

[coulof]

So CSI/snapshot clones normally create ephemeral snapshots, which should keep us within limits. Could you please attach some PowerStore source? I am probably misunderstanding the issue.

I want to ensure I poke at this a bit, since doing host assisted clones all over is going to be a major hit for anyone who uses this solution.

In PowerStore, a PVC restore from a Snapshot is actually a writable Snapshot. There are limited number of writable snapshot per LUN therefore we have to switch to host copy.

[akalenyu]

So CSI/snapshot clones normally create ephemeral snapshots, which should keep us within limits. Could you please attach some PowerStore source? I am probably misunderstanding the issue.
I want to ensure I poke at this a bit, since doing host assisted clones all over is going to be a major hit for anyone who uses this solution.

In PowerStore, a PVC restore from a Snapshot is actually a writable Snapshot. There are limited number of writable snapshot per LUN therefore we have to switch to host copy.

In that case, you also want to not use snapshots as golden sources (many VMs will restore from them), right

containerized-data-importer/doc/onboarding-storage-provisioners.md

Lines 18 to 19 in 1360dfd

	- Ceph rbd scales better when golden sources are stored as snapshots (more info in [clone-from-volumesnapshot-source](./clone-from-volumesnapshot-source.md))
	https://github.com/kubevirt/containerized-data-importer/blob/c6089cbcb01ab58e75b25be1770ce0f3f4625014/pkg/storagecapabilities/storagecapabilities.go#L109-L112

But my worries remain, host-assisted is a big hammer,
But other things could break too, for example, you're saying the number of VMSnapshot/VMRestores one can make is also limited?

[coulof]

@akalenyu, per documentation here & there

A thin clone is a read-write copy of a volume, volume group, or snapshot that shares blocks with the parent resource.... Thin clones are not full copies of the original source.

There is limit of 64 Max Clones per Family (A Family is a volume, volume group, or base storage container and all its derivative thin clones and snapshots).

As you can imagine you can quickly reach 64 VMs starting from a Golden image.

My understanding was that with the updated StorageProfile, the Golden image won't be restored from a snapshot but from a host copy.

We are investigating to add full-blown detached copy to PowerStore. But in the meantime it is probably wise to not rely on PVC Clone.

[akalenyu]

@akalenyu, per documentation here & there

A thin clone is a read-write copy of a volume, volume group, or snapshot that shares blocks with the parent resource.... Thin clones are not full copies of the original source.

There is limit of 64 Max Clones per Family (A Family is a volume, volume group, or base storage container and all its derivative thin clones and snapshots).

As you can imagine you can quickly reach 64 VMs starting from a Golden image.

My understanding was that with the updated StorageProfile, the Golden image won't be restored from a snapshot but from a host copy.

We are investigating to add full-blown detached copy to PowerStore. But in the meantime it is probably wise to not rely on PVC Clone.

Hey, I totally get the reasoning, I am just saying that the same problem could meet you further down the road
(vmsnapshot/vmrestore https://kubevirt.io/user-guide/storage/snapshot_restore_api/)

Anyhow, this decision is entirely up to you, but, for visibility I would appreciate an lgtm from
someone else here too
/approve
/cc @aglitke @peterclauterbach

[kubevirt-bot]

@akalenyu: GitHub didn't allow me to request PR reviews from the following users: peterclauterbach.

Note that only kubevirt members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

@akalenyu, per documentation here & there

A thin clone is a read-write copy of a volume, volume group, or snapshot that shares blocks with the parent resource.... Thin clones are not full copies of the original source.

There is limit of 64 Max Clones per Family (A Family is a volume, volume group, or base storage container and all its derivative thin clones and snapshots).

As you can imagine you can quickly reach 64 VMs starting from a Golden image.

My understanding was that with the updated StorageProfile, the Golden image won't be restored from a snapshot but from a host copy.

We are investigating to add full-blown detached copy to PowerStore. But in the meantime it is probably wise to not rely on PVC Clone.

Hey, I totally get the reasoning, I am just saying that the same problem could meet you further down the road
(vmsnapshot/vmrestore https://kubevirt.io/user-guide/storage/snapshot_restore_api/)

Anyhow, this decision is entirely up to you, but, for visibility I would appreciate an lgtm from
someone else here too
/approve
/cc @aglitke @peterclauterbach

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: akalenyu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [akalenyu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment