-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve auto_cleanup mechanism #4984
Comments
There is a proper for marking such VMs already: a DispVM class has a
|
disp
for automatically created DispVMs.
@marmarek if I may, I would suggest a bullet point covering cleanup of some of these remnants even if the system were not shutdown cleanly. e.g. volatile storage that was not removed in the last session. |
I'd prefer this (removing DispVM data after unclean shutdown) as a separate issue. |
The problem you're addressing (if any)
Some DispVMs are meant to be removed after they die, and leave no trace of their existence (except possibly logs). These include ones created by qrexec and by SaltStack. Others are somewhat more permanent: while the VM itself has no persistent state, some metadata (device assignments, qrexec policies, etc) should be preserved after the VM shuts off. For example, this includes
sys-usb
if it is a DispVM.Describe the solution you'd like
I propose that the qube name be used to distinguish these cases. Under this proposal, qube names that begin with
disp
are reserved as follows:disp
cannot be created explicitly via the Admin API, or byqvm-create
. They can only be created byqubesd
itself, and are always disposable.qubesd
uses names beginning withdisp
for all DisposableVMs that it creates itself, as opposed to qubes created explicitly via the Admin API. In particular, these can be created byqrexec
with a DispVM targetdisp
are killed when the API call that created them ends. This matches the current behavior ofqrexec
targeting a DispVM.disp
dies, it is cleaned up as followsqubes.xml
.Where is the value to a user, and who might that user be?
This mostly benefits users who make heavy use of SaltStack or
qvm-run --dispvm
. While the second case will go away in Qubes 4.1, the first will not, and has similar problems.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This is related to a bug reported against Docker. Both involved clients needing to clean up temporary resources after use, even though the server could have done that just as easily.
Relevant documentation you've consulted
None so far
Related, non-duplicate issues
#4253
The text was updated successfully, but these errors were encountered: