Preloaded DisposableVMs

[ejose19]

The problem you're addressing (if any)
Disposable vms are very useful for the intent they're made, however one drawback they have is that usage is not instant as other appvms, and one need to wait for it to load before using it (varying from 7-20s depending on hardware)

Describe the solution you'd like
It would be great if there was an option to "preload" the dispvm (quantity to preload would be defined by the user and limited by hardware specs) so whenever you need to use a dispvm the target program launches automatically.

Where is the value to a user, and who might that user be?
It would be a great benefit in terms of speed and convenience depending on how much the user relies on dispvms

Additional context
Currently behaviour would be preserved, if you launch a program for a dispvm using the qubes menu, each call would use a different preloaded dispvm, no reuse would be made. Also when one dispvm is "used", another one would be preloaded to keep the defined amount always ready.

[andrewdavidwong]

I know that @marmarek has discussed this idea before, but I'm not aware of any existing issue for it.

[unman]

It's much more difficult than it used to be because of the possibility of multiple DisposabeVMs - I dont see how we can preload all of them, can we? Unless we save state on the disposableVMs.

[ejose19]

@unman I was thinking more of a pool, the preloader register the dispvm ids/name and each time we launch a program to run under a dispvm, it would "pop" from the pool and run the program under that dispvm. Whenver there's many dispvms running at the same time shouldn't be an issue, only the registered ones will be used. If the pool is empty then it will just launch a dispvm like it currently does.

[brendanhoar]

There's work in Xen towards near-instantaneous VM forking, which would be perfect for this kind of application. Boot the default dvm and when up and ready, pause it for as many forks as necessary, once per invocation by any VM. Each use would be guarded against knowing about other uses, since each clone always instantiates at the initial pause/fork moment.

Would save memory too, if using multiple dvms at the same time.

https://patchwork.kernel.org/cover/11313385/

Might be ready for Xen 4.14:
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg72091.html
https://lore.kernel.org/xen-devel/000401d62aaa$e0eccab0$a2c66010$@xen.org/

It's likely going to be somewhat less than near-instantaneous for the Qubes use case, as forks of drive storage will be needed as well, but LVM is pretty quick in that area too.

Brendan

[marmarek]

Multiple DisposableVM Templates could be solved by configuration - you enable the feature only for some (the one you use the most). It is a trade-off, but IMO acceptable one.

As for VM-forking patches - no, it doesn't solve the problem. @unman is talking about DispVMs that are not coming from the same template. Anyway, while this feature indeed could be nice for DispVMs in theory, I'm afraid in practice it may be quite challenging to use - it is designed with assumption you normally have just one fork running and it is short-lived one (specific use case: fuzzing). Adopting it for multiple, long-running VMs will require it to be extended (for example there are performance issues when the forked VM is running longer).

[marmarek]

as forks of drive storage will be needed as well, but LVM is pretty quick in that area too.

Actually, this is something that could be improved. Depending on specific system, LVM setup for a VM takes few seconds (with otherwise fast machine, it could mean 1/3 or even 1/2 of VM startup time). I believe it is mostly caused by synchronization with udev, but I haven't verified it yet.

[brendanhoar]

indeed could be nice for DispVMs in theory, I'm afraid in practice it may be quite challenging to use - it is designed with assumption you normally have just one fork running and it is short-lived one (specific use case: fuzzing). Adopting it for multiple, long-running VMs will require it to be extended (for example there are performance issues when the forked VM is running longer).

Ok. I may have been off topic, as I was looking at it in the context of oft-touted Qubes features of "open an unsafe file" or "convert unsafe file to safe file".

I think vm forking would (theoretically) be a good fit for these, as those VMs are short lived and dedupe/copy-on-write memory explosion would therefore be unlikely.

Granted, I'm not the one having to make it work in practice, so I yield to your assessment.

B

[ideologysec]

I know nothing about how this would technically work with Xen, but, another option (further down the road) might be moving to ZFS as the underlying filesystem. In addition to making things like TemplateVMs more space efficient, it seems like it also be used to snapshot a paused dispVM template, and then Xen could simply resume as many snapshotted copies as needed (since zfs snapshots are just deltas from the originating blocks, and essentially "free" and definitely instantaneous.

https://github.com/jimsalterjrs/sanoid/