fix(vm): allow disk updates when VM is stopped

[hardcoretime]

Description

Fixed the issue where disk changes on a stopped VirtualMachine with WaitForFirstConsumer (wffc) volume binding mode were not being applied to the KVVM (intvirtvm) resource.

Changes made to pkg/controller/kvbuilder/kvvm_utils.go:

1. Added isVmRunning check to the paravirtualization condition in applyBlockDeviceRefs to allow new disks when VM is stopped
2. Updated cleanupRemovedStaticDisks function to accept isVmRunning parameter and remove all disks unconditionally when VM is stopped (not just non-hotpluggable ones)
3. Added VMBDA filtering to prevent removing disks that are attached via VirtualMachineBlockDeviceAttachment - these disks should remain in KVVM spec to be visible in stopped VM status

Added unit tests in pkg/controller/kvbuilder/kvvm_utils_test.go to verify:

• When VM is stopped: all disks not in VM spec are removed (regardless of hotpluggable flag)
• When VM is running: only non-hotpluggable disks not in VM spec are removed
• VMBDA-attached disks are preserved even when VM is stopped

Why do we need it, and what problem does it solve?

The DataExport e2e test was failing when using storage class with WaitForFirstConsumer (wffc) volume binding mode. The scenario:

1. Create a VM with one disk (vd-data)
2. Stop the VM
3. Run DataExport which:
   • Removes the original disk (vd-data)
   • Creates new disks from snapshot/source (vd-restored-from-disk, vd-restored-from-snapshot)
4. Start the VM

The VM got stuck in starting phase because:

• Old disk (vd-data) was NOT removed from KVVM (because it was marked as hotpluggable)
• New restored disks were NOT added to KVVM (because paravirtualization was enabled and VM had existing volumes)

This happened because the code was designed for running VMs with hotplug handler, not for stopped VMs where changes should be applied directly.

What is the expected result?

When a VM is stopped and disks are changed in the VM spec (disks added/removed), the KVVM resource should be updated accordingly. After the fix:

• Old disks not in spec are removed from KVVM (when VM is stopped)
• New disks in spec are added to KVVM (when VM is stopped)
• For running VMs, the behavior remains unchanged (hotplug handler manages disk changes)
• Disks attached via VMBDA are preserved in KVVM spec to remain visible in stopped VM status

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vm
type: fix
summary: "Fixed disk update for stopped VMs with WaitForFirstConsumer storage class. Previously, when a VM was stopped and disks were changed, the KVVM was not updated, causing the VM to get stuck in starting phase."

[deckhouse-BOaTswain]

Workflow has started.
Follow the progress here: Workflow Run

The target step completed with status: failure.

[deckhouse-BOaTswain]

Workflow has started.
Follow the progress here: Workflow Run

The target step completed with status: failure.