Files
cozystack/packages/apps/vm-disk
myasnikovdaniil 4087218a02 docs: move the repo-only guides onto the website (#5034)
## What this PR does

Seven guides under `docs/` were operator facing and written alongside
the code, and left in the source tree where no user looks. They are on
the website now, so this deletes them here and repoints every reference.

```
docs/operations/backup-classes.md                  -> operations/services/backup-classes
docs/operations/resource-presets.md                -> guides/resource-management
docs/storage-immutability.md                       -> operations/storage-class-immutability
docs/operations/system-memory-limits.md            -> operations/configuration/system-memory-limits
docs/gateway-classes.md                            -> networking/gateway-classes
docs/observability/distributed-tracing.md          -> operations/services/monitoring/distributed-tracing
docs/operations/seaweedfs-capacity-for-backups.md  -> operations/services/object-storage/capacity-for-backups
```

`docs/release.md`, `docs/deprecating-applications.md` and the two
SeaweedFS runbooks in `docs/operations/` stay. A workflow, `AGENTS.md`,
a migration and a bats suite read them by path, which is the test from
#3777.

References point at `https://cozystack.io/docs/v1/...`. The site
rewrites that short prefix to the latest version in `layouts/404.html`,
so the links follow releases and pin none. Backup Classes, resource
management and `storageClass` immutability exist in the latest version
already. The other four pages are only in `next/` until 1.7.0 is
promoted, and their links start to resolve then. The generated mongodb
files come from `values.yaml` through `make generate` with
cozyvalues-gen v1.7.0, the version pinned in
`.github/workflows/pre-commit.yml`.

Tests: helm unit tests for mongodb (151), postgres (209), vm-disk (114)
and kubernetes-nodes (223), go tests for backupcontroller, presets and
the operator, rd-presets-check, the migration-50 bats suite.

### Downstream repositories

- [x] [cozystack/website](https://github.com/cozystack/website) -
follow-up: cozystack/website#763

Walked the rest of the trigger map against the diff. No provider
follow-up: the mongodb `values.schema.json` diff is one `description`
string, with no field added, removed or renamed, no enum, no default,
and no `kind`, `plural` or `release.prefix` change.
`packages/core/platform/values.yaml` changed in comments only and no
key, so the hand written platform-package table on the site is
unaffected.

Please merge after cozystack/website#763, the links in the code only
resolve once those pages deploy.

### Release note

```release-note
docs: seven guides move from the docs/ directory of this repository to cozystack.io (Backup Classes, resource presets, storageClass immutability, system component memory limits, GatewayClass selection, distributed tracing, SeaweedFS capacity for backups), and in-repo references point there.
```
2026-11-03 23:09:46 +05:00
..
2025-09-18 16:27:38 +02:00
2024-10-16 18:35:30 +02:00
2025-09-24 12:32:37 +02:00

Virtual Machine Disk

A Virtual Machine Disk

storageClass and source are annotated as immutable in the chart schema — see storageClass immutability for the contract and which consumers enforce it. DataVolume.spec is immutable in CDI, so the chart also fails the release on an attempted storageClass/source edit of an existing disk rather than silently reusing the old spec; delete and recreate the disk to change either field.

Whether CDI has finished populating the disk shows up in the WorkloadsReady condition, not in Ready, which follows the Helm release and does not wait on the DataVolume: WorkloadsReady stays False while an import, clone or upload is in flight and when the DataVolume fails. Its message names the DataVolume and the phase it is in, followed by the error CDI reports for the pod populating the disk when there is one, such as a 404 or an unresolvable host on an HTTP source: CDI keeps retrying such an import, so its phase stays ImportInProgress, and the error is shown between retries rather than while a retry is running. kubectl get vmdisks shows the condition in the WORKLOADS column, and the console badge reads DataVolumeNotReady until it is True. A disk created before this behaviour was introduced keeps its old release settings, under which Ready may wait on the DataVolume, until its application is next updated. A source.upload disk reads False from the moment it is created until virtctl image-upload completes, because CDI reports waiting for the upload and receiving it as one phase. A disk counts as ready while it waits for its consumer with bindImmediately off on a WaitForFirstConsumer class, because that is a state such a disk is supposed to rest in.

bindImmediately is on by default, so a disk's volume is provisioned when the disk is created rather than deferred to the first consumer. That default exists because a VMDisk is a standalone object with a lifecycle of its own: on a WaitForFirstConsumer StorageClass a disk that no VM has attached yet would otherwise never populate at all. It costs something on a node-pinned class such as local, where the CDI worker pod becomes the first consumer and the volume lands where that pod was scheduled rather than where the VM will run, so a VM whose placement is constrained (a nodeSelector, a resource request only one node satisfies, or the Windows affinity applied by _cluster.scheduling.dedicatedNodesForWindowsVMs) can stay unschedulable against a node-affinity conflict, and storageClass is immutable so the only exit is deleting and recreating the disk. Turn bindImmediately off for a disk a VMInstance will consume on such a class: KubeVirt then renders a temporary launcher pod carrying the VM's own affinity and node selector, and the volume binds where the VM can actually run. The chart default replicated binds Immediate regardless, so neither setting changes anything there.

A disk created from source.image should use the StorageClass its golden image lives in, replicated in the default layout. When CDI clones with the csi-clone strategy, the platform default, into a different StorageClass of the same CSI driver with the same volume mode and room to expand, it does not fall back to a host-assisted copy and leaves the clone to the driver. The snapshot strategy does the same when it gets a VolumeSnapshotClass of that driver: the class both StorageProfiles name, or, when they do not name the same one, any class of the driver. LINSTOR creates that clone next to the source data, so on a target class that does not allow remote volume access from every node, such as a node-local class, the clone may never bind. The chart refuses such a new disk when the golden's driver and the target class's provisioner are both LINSTOR and the target's allowRemoteVolumeAccess is not a value linstor-csi reads as true (1, t or true, in any of the cases Go's strconv.ParseBool accepts); any other value is a list of rules, and the chart counts it as access from anywhere only when one rule names no fromSame label. Without that parameter it reads the target's layer list the way linstor-csi does, which allows remote access when it has a DRBD or NVMe layer, and a class that sets no layer list has DRBD. Under snapshot, it also refuses a disk whose golden and target StorageProfiles name the same VolumeSnapshotClass when that class does not exist and the golden's driver is the target class's provisioner, whatever the driver: CDI then fails to plan the clone instead of falling back. Both refusals compare only what they can look up: without the golden image's PVC, the cdi resource or the target's StorageClass nothing is compared. The remote access refusal also needs the target's StorageProfile with a claim property set and the golden's driver, taken from its bound PV or else from its StorageClass; when any of them is missing, the disk renders. Neither applies to a disk whose DataVolume or PVC already exists. Use the golden image's StorageClass instead, or ask the platform administrator to set cloneStrategyOverride: copy in the kubevirt-cdi package, which clones through a host-assisted copy in every case. The remote access refusal leaves alone a target class that allows remote volume access, a driver other than LINSTOR, a target class of another driver, a different volume mode, a class without volume expansion, snapshot that gets no VolumeSnapshotClass of the driver, and the copy strategy. An empty storageClass is compared as the class CDI would pick for it: the class annotated storageclass.kubevirt.io/is-default-virt-class, otherwise the class annotated storageclass.kubernetes.io/is-default-class; when several classes carry the annotation that decides, nothing is compared.

Parameters

Common parameters

Name Description Type Value
source The source image location used to create a disk. object {}
source.image Use image by name from default collection. *object null
source.image.name Name of the image to use. string ""
source.upload Upload local image. *object null
source.http Download image from an HTTP source. *object null
source.http.url URL to download the image. string ""
source.disk Clone an existing vm-disk. *object null
source.disk.name Name of the vm-disk to clone. string ""
optical Defines if disk should be considered optical. bool false
storage The size of the disk allocated for the virtual machine. quantity 5Gi
storageClass StorageClass used to store the data. string replicated
bindImmediately Provision the volume at disk creation instead of waiting for a consumer. bool true