Can we provision independent persistent disk using vsphere csi driver?

[shindebshekhar]

What happened:
By default dependent persistent disk are provisioned. As per some of our backup tool requirement we need to provision independent persistent disk.

What you expected to happen:
Feature that provides provisioning of independent persistent disk

Anything else we need to know?:

Environment: rke2 cluster v1.28.8+rke2r1 3Master 3 Worker nodes

• csi-vsphere version: vsphere-csi-release-driver: v3.0.1
• vsphere-cloud-controller-manager version: mirrored-cloud-provider-vsphere-cpi-release-manager:v1.26.1
• Kubernetes version: v1.28.8+rke2r1
• vSphere version: 7.0
• OS (e.g. from /etc/os-release): SUSE Linux Enterprise Server 15 SP3
• Kernel (e.g. uname -a): 5.3.18-150300.59.147-default

[divyenpatel]

@shindebshekhar what is independent persistent disk?

[slimm609]

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-8B6174E6-36A8-42DA-ACF7-0DA4D8C5B084.html

Dependent: Dependent mode is the default disk mode. When you take a snapshot of a virtual machine, dependent disks are included in the snapshot. When you revert to the previous snapshot, all data are reverted to the point of taking a snapshot.

Independent - Persistent: Disks in persistent mode behave like conventional disks on your physical computer. All data written to a disk in persistent mode are written permanently to the disk even if you revert a snapshot. When you power off or reset a virtual machine, the disk and all its snapshots are preserved.

Independent - Nonpersistent: Disks in nonpersistent mode behave like read-only disks. Changes to disks in nonpersistent mode are discarded when you power off or reset the virtual machine. With nonpersistent mode, you can restart the virtual machine with a virtual disk in the same state every time. Changes to the disk are written to and read from a redo log file that is deleted when you power off or reset the virtual machine, or when you delete a snapshot.

[viveksyngh]

These are disk mode as documented here is go vsphere client. https://github.com/vmware/govmomi/blob/fb9679e76d104a9619f13a35e020f30ba25f14be/vim25/types/enum.go#L11850

Looks like vsphere cloud provider used to create the disk with Independent Persistent mode VirtualDiskModeIndependent_persistent https://github.com/kubernetes/cloud-provider-vsphere/blob/32f7c3363db21331e476c4e4af00426f28827d42/pkg/common/vclib/virtualmachine.go#L244

But I could not find any reference for this in the vSphere CSI provider repo and I assume by default it is creating with dependent disk mode as we have noticed in our environment.

[danielkucera]

I am also interested in this. We would like to be able to create a snapshot of all cluster nodes (including workers) before doing an upgrade to be able to revert in case of failed upgrade.
In this case it makes no sense to snapshot also the CSI volumes which are related to the workload.
Additionally, if the worker VM snapshot was created together with CSI volumes attached as dependent, it is impossible to unattach them until the snapshot is deleted - the workload cannot be moved to another node.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[danielkucera]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[danielkucera]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten