Skip to content

[Backport release-1.4] fix(csi): verify VMI Ready after kubevirt-csi Publish to surface stuck-PVC failures - #2748

Merged
myasnikovdaniil merged 2 commits into
release-1.4from
backport-2659-to-release-1.4
May 27, 2026
Merged

myasnikovdaniil merged 2 commits into
release-1.4from
backport-2659-to-release-1.4

Conversation

@github-actions

Copy link
Copy Markdown

Description

Backport of #2659 to release-1.4.

Upstream ControllerPublishVolume has a fast path that returns success
based only on the volume's presence in VM.spec.template.spec.volumes
(via EnsureVolumeAvailableVM). If a prior Publish wrote that entry but
the volume never became Ready in VMI status - e.g. the infra PVC is
stuck ClaimPending because LINSTOR cannot autoplace - the retry hits
the fast path and reports success. external-attacher marks the
VolumeAttachment Attached=true, but QEMU was never sent device_add, so
the tenant kubelet fails NodeStageVolume with:

    rpc error: code = Unknown desc = couldn't find device by serial id

Wrap upstream Publish for hotplug volumes (non-NFS) with a post-call
check that the volume reached VolumeReady in VMI.Status.VolumeStatus.
When it has not, the RPC returns codes.Unavailable carrying the actual
reason (e.g. "PVC is in phase ClaimPending"), so external-attacher
keeps retrying and the underlying provisioning failure is visible at
the CSI layer rather than as a confusing "device not found by serial
id" on the tenant kubelet.

This is a wrapper-side workaround for an upstream defect in
kubevirt.io/csi-driver; the structural fix belongs upstream (tighten
the fast path to require VMI Ready) and will be filed separately.

Assisted-By: Claude <[email protected]>
Signed-off-by: Myasnikov Daniil <[email protected]>
(cherry picked from commit 5bb5e95)
…nnot run

The fallback branches in publishHotplugVolume silently returned the
upstream success response when the node ID failed to parse or the VMI
get call returned an error. external-attacher then set Attached=true
without VolumeReady proof, which recreates the false-positive attach
this wrapper exists to prevent.

Fail loudly instead:

- parseErr -> codes.Internal: external-attacher is expected to provide
  a well-formed "namespace/name" node ID per the CSI contract; if it
  does not, surface the contract violation rather than mask it.
- getErr -> codes.Unavailable: this is the same code returned for the
  not-Ready and not-present cases just below, so the retry behavior on
  the attacher side stays consistent. By the time we reach this branch
  the upstream Publish call already succeeded, which means it just
  looked the VMI up; a transient get error here is a race or API hiccup
  and a retry is safe.

Also add a one-line comment on GetVirtualMachine: in the upstream
kubevirt.io/csi-driver client this method returns a
VirtualMachineInstance despite its name, so accessing
vmi.Status.VolumeStatus on the result is type-correct.

Assisted-By: Claude <[email protected]>
Signed-off-by: Myasnikov Daniil <[email protected]>
(cherry picked from commit cbe4b86)
@dosubot dosubot Bot added area/storage Issues or PRs related to storage (linstor, seaweedfs, bucket, velero, harbor) area/virtualization Issues or PRs related to virtualization (kubevirt, cdi, vmi, vm-import) kind/backport Categorizes issue or PR as requiring a backport to the current release line kind/bug Categorizes issue or PR as related to a bug labels May 26, 2026
@myasnikovdaniil
myasnikovdaniil merged commit d046606 into release-1.4 May 27, 2026
4 of 5 checks passed
@myasnikovdaniil
myasnikovdaniil deleted the backport-2659-to-release-1.4 branch May 27, 2026 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/storage Issues or PRs related to storage (linstor, seaweedfs, bucket, velero, harbor) area/virtualization Issues or PRs related to virtualization (kubevirt, cdi, vmi, vm-import) kind/backport Categorizes issue or PR as requiring a backport to the current release line kind/bug Categorizes issue or PR as related to a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant