Kill a paused qube before system shutdown

[alimirjamali]

fixes: QubesOS/qubes-issues#8580

[marmarek]

This doesn't look right. If a qube was paused, it was likely done for a reason, it shouldn't execute anything without explicit user action. Maybe kill paused qubes on shutdown instead?

[alimirjamali]

Maybe kill paused qubes on shutdown instead?

This sounds more dangerous. What if the qube had open applications with proper auto-save on shutdown mechanism. Killing qube might lead to serious data-loss. Having said that, killing disposables might be a legitimate option.

[marmarek]

Ideally, we'd ask the user, but I don't think we have any way to do that. The autosave is one scenario, but if user wanted to interact with such a qube, why it was paused? Another scenario could be some misbehaving qube paused to limit damage - unpausing it would be very wrong here.

[alimirjamali]

So properly killing it would be the way. I will look into libvirt_domain to find the clean way to kill a paused domain. libvirt_domain.shutdown() fails to do it for suspended domains.

p.s.: And documentation should be updated that paused domain will be killed on shutdown.

[marmarek]

See what qvm-kill does. BTW, I think killing should be only during system shutdown. Normal qvm-shutdown should not automatically change to killing on a paused qube but maybe show an error or some other message?

[alimirjamali]

@marmarek It is done. qvm-pause documentation is also updated to reflect this behaviour. Considering the fact that the existing behaviour is also indeed killing of paused qubes on shutdown, nothing is really changed here. It is only cleaner and much faster.

[alimirjamali]

Normal qvm-shutdown should not automatically change to killing on a paused qube but maybe show an error or some other message?

Ops. Just saw this. I will work on it.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 69.31%. Comparing base (68070df) to head (8344dad).

Files with missing lines	Patch %	Lines
qubes/vm/qubesvm.py	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #616      +/-   ##
==========================================
- Coverage   69.33%   69.31%   -0.03%     
==========================================
  Files          58       58              
  Lines       11946    11950       +4     
==========================================
  Hits         8283     8283              
- Misses       3663     3667       +4     

Flag	Coverage Δ
unittests	69.31% <0.00%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alimirjamali]

@marmarek I believe it is done properly.

Trying to shutdown a paused qube will raise proper error (instead of doing nothing).
Shutdown with --force will destroy it (instead of waiting).

Please let me know if you are OK with it, so I could proceed with updating unittests.

This is the screenshot of the error:

[alimirjamali]

Reason for amendment: Making Pylint happy(er)

[marmarek]

Please let me know if you are OK with it, so I could proceed with updating unittests.

Yes, this looks reasonable

[alimirjamali]

It appears that CI/CD is broken at the moment.

I do not have access to PipelineRetry

[alimirjamali]

OK. Codecov is advising on the necessary unittests. I have a crude idea on the required unittest. Might be wrong

[alimirjamali]

@marmarek It appears that none of the basic integration unittests are executed. I am having trouble to find the proper unittest to update for this.

[marmarek]

Integration tests are not running in gitlab-ci, they are running only in openqa, see https://www.qubes-os.org/doc/automated-tests/