Bug 2027959

The default for Windows is deliberately set to be a high value. The rationale behind this is that Windows tends to apply updates during shutdown. Setting a lower value by default can lead to a situation where data corruption can occur.

If a user prefers a lower value, a custom template can be created.

Additionally it's possible to apply the --grace-period argument when attempting to delete a resource.

I'm closing this BZ based on the above. If you think this is in error, please feel free to re-open.

CNV could try to do something a little bit more elaborate, like RHV does.

If the VM is not considered Up (any OS), it will kill the VM immediately, without waiting.

The question is then what is an Up VM:

    private boolean canShutdownVm() {
        return (getVm().getStatus() == VMStatus.Up
                || getVm().getStatus().isMigrating() && getVmManager().getLastStatusBeforeMigration() == VMStatus.Up)
                && (Boolean.TRUE.equals(getVm().getAcpiEnable()) || getVm().getHasAgent());
    }

After starting a VM, it will be 'Up' once the Guest agent connects, or it reaches a timeout - GUEST_WAIT_TIMEOUT - for VMs without Guest agent.

So if it fails to boot, I can easily and quickly power it off again via the UI without having to wait 1h or run manual commands, or eventually have a customer to contact support just to shutdown a VM that is stuck trying to power off for 1h.

Stuart, sorry to re-open this but its highly annoying.

I've just hit it again on a failed windows install, try to shutdown it during Windows install from ISO (I forgot to set a specific setting I wanted) hits the same thing as the OS won't shutdown by itself.

Also, support frequently helps customers when some upgrade makes the Guest fail to boot (both Windows and Linux) and gets stuck on boot loader or something similar: the guest must be powered off and a CD used for recovery. Waiting 1h for windows is not nice and even the 3m for linux is not great.

Could you please take a look at comment #2? Or maybe add another button on the console plugin to "Power Off".

Thank you!

Tal,

Given that there exists a mechanism to shut down immediately from the CLI, is this request something the UI could incorporate? Per comment #3?

Per the conversation so far, it appears the request here is to create a UI workflow, thus re-assigning to the UX component. Please feel free to re-assign if this action appears to be in error.

Created attachment 1851667 [details]
The text in the popover should be reviewed by the docs team

Created attachment 1851668 [details]
The text in the popover should be reviewed by the docs team

Created attachment 1851815 [details]
Updated

Created attachment 1851816 [details]
No need for the units dropdown

The help text source is https://kubevirt.io/api-reference/master/definitions.html#_k8s_io_apimachinery_pkg_apis_meta_v1_deleteoptions

@sgott We would like to implement "force delete" action for a terminating VM and wondered is it possible to send a new delete (api call) to a VM that is stuck in the delete process.
Thanks.

Please note it's not about VM is stucking in "Terminating", it's the POD and PVC stucking in "Terminating".
Tested the posted PR, still see the same thing, pod and PVC is staying in "Terminating".

Hi Yifat, we're tracking the request in Comment #11 here:

https://bugzilla.redhat.com/show_bug.cgi?id=2040766

The basic issue here is that the API rejects deletion requests if a deltion has already been requested. In the case that the user is attempting to force deletion of a VM stuck in terminating, this should be honored.

Thank you Stu. As the ui depends on the solution for this bug https://bugzilla.redhat.com/show_bug.cgi?id=2040766, we would like to know when is it targeted for?

Just tested that if the pod is stucking in "terminating", delete the virt-launcher pod from CLI also does not work.

$ oc delete pod virt-launcher-win10-israeli-lamprey-m2z8g --grace-period=30
The above command does not delete the pod after 30s.

So this is a virt bug as '--grace-period' is not working.

Reproduce steps:
1. create a windows VM from UI, check "This is a CD-ROM boot source" on the boot source step
2. wait until the VM is running
3. delete the VM
4. VM is deleted, but the virt-launcher pod is stucking in "terminating"
5. delete the pod from CLI by specify the grace period
6. pod is not deleted after the grace period

moving to new, because we need a fix from virt team

I'm confused by the re-assignment of this BZ. We'll be fixing the --grace-period issue here https://bugzilla.redhat.com/show_bug.cgi?id=2040766

If this BZ is now being considered the same thing (per comment #15), then is it a duplicate?

Hi

So we have 2 issues the prevented us from fixing this on the UI side:
a - a VM that is forcefully killed (e.g. --grace-period is reached) does not clean up it's resources (PVC and Pods).
b - once a delete VM is sent the first time, a user can't send a force kill even if the VM is stuck while trying to delete.

AFAIU:
a -
This bug is open the track cleaning up after a force kill of the VM:
Actual results:
Pods and PVC persist after VM is forcefully shut down. 
Expected result:
Pods and PVC are garbage collected after VM is forcefully shut down.

b-
We also have another bug to track sending a "please adjust grace-period" to a VM that is currently being shut down.

c-
I thinkg https://bugzilla.redhat.com/show_bug.cgi?id=2040766 is related but a slightly different issue.

Yaacov,

You mentioned that pods do not clean up their resources. We expect they do. Do you have a concrete example you can provide that shows PVC/Pods sticking around after a VM is forcefully killed?

Prita,

We suspect this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2040766 so assigning it to you. I expect that this will likely be closed as a duplicate or marked as TestOnly. The only outstanding question is per Comment #19

hi, 
I never tested it myself, I was referring to step 6 in https://bugzilla.redhat.com/show_bug.cgi?id=2027959#c15 

```
Reproduce steps:
1. create a windows VM from UI, check "This is a CD-ROM boot source" on the boot source step
2. wait until the VM is running
3. delete the VM
4. VM is deleted, but the virt-launcher pod is stucking in "terminating"
5. delete the pod from CLI by specify the grace period
6. pod is not deleted after the grace period

```

As a result of this BZ or any closed as a DUP I'd like to have at least an easy (via UI) way for users to power off VMs regardless of their state, or ideally let kubevirt handle these VMs automatically by powering off immediately if there is no OS running or frozen, without waiting for huge timeouts.

Per comment #22 moving this to the UI component.

@tnisan @sgott does this depend on any backend functionality? If it does, where does it stand?

Backend functionality was provided in https://github.com/kubevirt/kubevirt/pull/7494

This behavior is present in 4.11.0 and newer. KubeVirt now accepts subsequent stop requests with a shorter termination grace period seconds.

Hi Ugo,
I think this option should be added to "Stop" as well, not only on "Delete", what do you think?

Yes, good idea :-) 
We don't have a stop modal. I'll create it.

The issue is still existing in 4.13, steps to reproduce:
1. create a windows vm from http://cnv-qe-server.rhevdev.lab.eng.rdu2.redhat.com/files/cnv-tests/windows-images/raw_images/win11_validationos_amd64.iso
2. wait for the VM turn into running
3. delete the VM and set the grace period to 60 seconds in the delete modal
4. the VM is not deleted after 60 seconds

@gouyang Seems like the request for delete with gracePeriodSeconds is done fine. Maybe backend can reproduce.

{
    "kind": "DeleteOptions",
    "apiVersion": "v1",
    "gracePeriodSeconds": 10
}

The bug https://bugzilla.redhat.com/show_bug.cgi?id=2182333 is for backend, if the backend does not fix it, it make no sense to add the option on UI as it won't work.

If the backend issue can be fixed, then we need to add the functionality for Stop action.

@gouyang do we need to add the stop action grace period functionality on this bug?

(In reply to Ugo Palatucci from comment #38)
> @gouyang do we need to add the stop action grace period
> functionality on this bug?

Let's adding it anyway, aligns with the delete modal.

Hei @gouyang We need to investigate a little bit more to add the functionality for the Stop modal.

This is because the parameters for the Delete are well defined in DeleteOptions, but the stop has no parameters.

What we are thinking is deleting the VMI using the grace period defined in the DeleteOptions, but I have to discuss it a little bit with someone from the backend team and see if it's a good strategy.

i was wrong. Stop has parameters and i've just created a pr to have grace period on stop

verified on kubevirt-console-plugin-rhel9-container-v4.14.0-1011

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Virtualization 4.12.5 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:4421