[itayherzberg]

Problem

While a virtual media import is in progress (importing.redfish/<device> label on the VM) every ComputerSystem.Reset is deferred, ForceOff and GracefulShutdown included:

POST .../Actions/ComputerSystem.Reset {"ResetType":"ForceOff"}
202 {"Messages":[{"Message":"Power action ForceOff deferred until ISO import completes"}]}

Two consequences:

• A host whose import does not finish cannot be powered off through Redfish at all. That is exactly the state a host is in when its import pod is stuck (for example on the RWO ISO volume that a prematurely started VM holds, see fix(server): Power On right after InsertMedia started the VM before its ISO import (empty CD-ROM, import pod stuck on the RWO volume) #36): Ironic gives up on the host, sends a power-off, gets a 202, and the VM keeps running. The host cannot be recovered through its BMC, only by stopping the VM by hand.
• A power-off that arrives after a deferred power-on does not cancel it: the deferred command is overwritten with ForceOff, the VM is left as it is, and whatever was recorded last runs when the import ends. Ironic asked for the host to be off; a host that starts on its own afterwards is a surprise.

Cause

handlePowerAction asks IsImportInProgress and, if true, records the reset type in power-after-import.redfish and answers 202 for any reset type. The deferral exists so that a VM is not started before its CD-ROM has an image; stopping a VM has nothing to wait for.

Fix

• Only an action that leaves the VM running waits for the import: On, ForceRestart, GracefulRestart (powerStateStartsVM). Everything else runs immediately.
• A power-off that runs while an import is pending first withdraws a deferred power-on (ClearPowerAfterImportLabel, a new metadata-only patch next to SetPowerAfterImportLabel). The withdrawal comes before the stop: if it failed afterwards the VM would still start when the import ends, which is the worse outcome. A failed withdrawal is a 500; the deferred command is then still recorded and nothing has changed.
• Pause and Resume also run immediately; they act on a running VMI and have nothing to do with the import.

Behaviour changes: ForceOff and GracefulShutdown are never deferred; while an import is pending they answer 200 and remove a power-after-import.redfish label (logged as Withdrew deferred power command On from VM ...). On/ForceRestart/GracefulRestart are deferred as before.

Verification on the cluster

OpenShift 4.22 / OpenShift Virtualization 4.22, the bridge built from fork main with #36 and this branch, an ISO served from an in-cluster nginx rate-limited to 1.5 MB/s (about 60 s per import). Against a halted VM: InsertMedia, then On once the importing label is on the VM, then ForceOff:

20:02:17 On:        deferred HTTP=202       power-after-import.redfish=On
20:02:19 ForceOff:  executed successfully HTTP=200   (took 3 s)
20:02:22 power-after-import.redfish=<none>  importing.redfish/cdrom0=copy-iso-rl-vm-1-...   ← import still running
20:03:31 import done: status=Stopped  vmi=<none>  power-after-import.redfish=<none>          ← VM did not start

Bridge log:

18:02:18.716Z Power action On deferred for VM redfish-prtest-vms/rl-vm-1 (import in progress)
18:02:21.514Z Withdrew deferred power command On from VM redfish-prtest-vms/rl-vm-1
18:02:22.308Z Successfully force stopped VM redfish-prtest-vms/rl-vm-1
18:03:18.179Z Removed importing label importing.redfish/cdrom0 from VM redfish-prtest-vms/rl-vm-1

No executed deferred power command line followed the label removal; the VM stayed halted with the finished ISO in its CD-ROM.

Tests

pkg/server/power_off_while_importing_test.go, with a halted VM that carries the importing label: On, ForceRestart and GracefulRestart answer 202 deferred and record themselves; ForceOff and GracefulShutdown answer 200, record nothing and leave the VM halted; after a deferred On, a ForceOff or GracefulShutdown removes power-after-import.redfish and leaves the importing label alone. On current main both tests fail with ForceOff: status 202 ... "Power action ForceOff deferred until ISO import completes". pkg/kubevirt/power_after_import_test.go: ClearPowerAfterImportLabel removes only that label, is a no-op without it, and errors on a missing VM.

go build ./..., go vet ./..., go test ./..., gofmt, go mod tidy (no change) pass.

Related

• fix(server): Power On right after InsertMedia started the VM before its ISO import (empty CD-ROM, import pod stuck on the RWO volume) #36 writes the importing label before InsertMedia is answered, so the deferral starts earlier; this PR decides which actions the deferral applies to. Independent hunks; a tree with both merges cleanly, and the run above used one.
• fix(kubevirt): a failed ISO import must not start the VM, read as inserted, or block a re-insert #39 withdraws the deferred power command when an import pod fails, the third way a host used to start on an empty CD-ROM.

[kubevirt-prow]

Hi @itayherzberg. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[MarSik]

/lgtm
/approve

[kubevirt-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MarSik

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [MarSik]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment