Skip to content
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

Open
DemiMarie opened this issue Apr 18, 2019 · 3 comments
Open

Improve auto_cleanup mechanism #4984

DemiMarie opened this issue Apr 18, 2019 · 3 comments
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.

Comments

@DemiMarie
Copy link

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:

  • Qubes with names that begin with disp cannot be created explicitly via the Admin API, or by qvm-create. They can only be created by qubesd itself, and are always disposable.
  • qubesd uses names beginning with disp for all DisposableVMs that it creates itself, as opposed to qubes created explicitly via the Admin API. In particular, these can be created by
    • qrexec with a DispVM target
    • A new API call to create a management VM, which will be used by SaltStack and other management tools.
  • Qubes with names that start with disp are killed when the API call that created them ends. This matches the current behavior of qrexec targeting a DispVM.
  • Whenever a qube with a name that starts with disp dies, it is cleaned up as follows
    1. All qrexec policy rules mentioning it are purged.
    2. The VM’s storage is removed.
    3. The VM record is purged from qubes.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

@DemiMarie DemiMarie added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement labels Apr 18, 2019
@marmarek
Copy link
Member

There is a proper for marking such VMs already: a DispVM class has a auto_cleanup property which means: remove the VM when it's terminated. I think it's much more elegant than reserving some particular names.
In relation to this issue, the mechanism should be extended to:

@andrewdavidwong andrewdavidwong changed the title Reserve VM names starting with disp for automatically created DispVMs. Improve auto_cleanup mechanism Apr 19, 2019
@andrewdavidwong andrewdavidwong added this to the Release 4.1 milestone Apr 19, 2019
@brendanhoar
Copy link

@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.

@marmarek
Copy link
Member

I'd prefer this (removing DispVM data after unclean shutdown) as a separate issue.
Some of it is already done, but apparently not everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.
Projects
None yet
Development

No branches or pull requests

4 participants