Skip to content

Persistent EFI/TPM on default storage blocks live-migration of Windows 11/2022/2025 VMs (regression in v1.5.0) #3005

Description

@kvaps

What happened

Commit 4cc60e3 (released in v1.5.0) removed the sed -i '/persistent: true/d' strip from packages/system/kubevirt-instancetypes and restored upstream's persistent firmware state for the windows.11, windows.2k22, windows.2k25 preferences (and their .virtio variants):

devices:
  preferredTPM:
    persistent: true
firmware:
  preferredEfi:
    persistent: true
    secureBoot: true

That was a correct fix (the strip left preferredTPM: null, which the v1.8 CRD rejects). But it has a side effect on live-migration.

With persistent EFI/TPM, KubeVirt creates a backend-storage PVC (persistent-state-for-<vm>). Its access mode is decided by backend-storage.getAccessMode: with vmStateStorageClass unset (the default), it consults the CDI StorageProfile of the cluster-default StorageClass. On the default replicated (linstor.csi.linbit.com) class the StorageProfile advertises only Filesystem: [ReadWriteOnce] (RWX is Block-only), so the backend PVC is created ReadWriteOnce.

An RWO backend PVC pins the VM to its node, so the VM cannot be live-migrated or drained.

Impact

On a default v1.5.0 install, windows.11 / windows.2k22 / windows.2k25 VMs are no longer live-migratable. Because the KubeVirt CR uses evictionStrategy: LiveMigrate and workloadUpdateMethods: [LiveMigrate, Evict], node drains and cluster upgrades involving these VMs can get stuck on the failed live-migration.

This is a behavioral regression vs. ≤ v1.4.x, where persistence was stripped (no backend PVC, migration worked — at the cost of non-persistent firmware state).

How to reproduce

  1. Install cozystack v1.5.0.
  2. Create a windows.2k22 VMInstance on the default replicated storage.
  3. kubectl get pvc → persistent-state-for-<vm> is ReadWriteOnce.
  4. Trigger a live-migration / node drain of that VM → blocked.

Possible directions

Environment

  • cozystack v1.5.0 (regression introduced by 4cc60e3; not present in ≤ v1.4.4)
  • KubeVirt v1.8.2, default replicated StorageClass (linstor.csi.linbit.com)

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/virtualizationIssues or PRs related to virtualization (kubevirt, cdi, vmi, vm-import)
    on Jun 22, 2026
  2. added
    kind/regressionCategorizes issue or PR as related to a regression from a prior release
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete
    on Jul 1, 2026
  3. lexfrei commented on Sep 6, 2026

    @lexfrei
    Contributor

    Closing this: the premise does not hold, and the disproof is already in our own changelog.

    The v1.5.4 entry for restoring persistent EFI/TPM (#3154) states that the strip was motivated by a concern resting on an outdated premise, and that KubeVirt has migrated RWO-Filesystem backend storage since v1.4 (kubevirt/kubevirt#12629): it creates a fresh target state PVC and copies the state blob during migration. It records that this was verified on the default replicated class, with a persistent-firmware VM reporting LiveMigratable=True.

    That behaviour predates the version this issue was filed against, so the RWO backend PVC never pinned the VM the way the description assumes. backend-storage.go is unchanged in this respect between v1.8.2 and the v1.9.0 we now ship.

    What is left is not migration: copy-on-migrate churns a fresh 10Mi PVC on each migration and deletes the old one, which is waste rather than breakage. The vmStateStorageClass knob in #3989 stands on its own merits rather than as a fix for this. If anyone reproduces a blocked migration on current main, please reopen with the condition or event that blocked it, since it will be a different mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/virtualizationIssues or PRs related to virtualization (kubevirt, cdi, vmi, vm-import)kind/bugCategorizes issue or PR as related to a bugkind/regressionCategorizes issue or PR as related to a regression from a prior releasepriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to completetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions