qemu: install various versions

[thomas]

Rationale:

• updating system qemu might be dangerous for production
  environments like github/labfolder

• having more recent versions at hand allows testing,
  and for easier use by regular users.

Difference to qemu installed in the system is the lack of the
virtfs-feature, since it would require to run qemu as root
(same would apply for the virtfs-proxy-helper).

[pmenzel]

From the discussion in mariux64/bee-files#1846 I’d have thought, that the virtfs feature could be used for non-root users.

And as QEMU is used mainly by the administrators, which are able to become root, I’d vote for leaving the feature enabled – especially to avoid confusion.

Nevertheless, we should discuss in our group, what the merit of pkg-scripts is. In my opinion it has diverted from giving our scientists “reproducible development environments” (scripts).

[thomas]

On 2020-07-13 12:04, Paul Menzel wrote: From the discussion in mariux64/bee-files#1846 I’d have thought, that the virtfs feature could be used for non-root users.

Maybe I was wrong, and it affects only the things that root can do (like mounting?). Another issue is that qemu-5 doesn't build out of the box with virtfs. And I have another one too, we have never used it in the past.

And as QEMU is used mainly by the administrators, which are able to become root, I’d vote for leaving the feature enabled – especially to avoid confusion.

This holds no longer true, since it's intended to relase quemu to the users, giving them the option to do their own docker/apt install stuff (if they like).

Nevertheless, we should discuss in our group, what the merit of pkg-scripts is. In my opinion it has diverted from giving our scientists “reproducible development environments” (scripts).

The merrit was explained in the commit message, at least I thougt so. We can keep 'our' sensible qemu, and users may use qemu3,4,5 all reproducible via the pkg/bla-version mechanism.

…

-- Thomas Kreitler - Information Retrieval kreitler@molgen.mpg.de 49/30/8413 1702

[pmenzel]

On 2020-07-13 12:04, Paul Menzel wrote:

From the discussion in mariux64/bee-files#1846 I’d have thought, that the virtfs feature could be used for non-root users.
Maybe I was wrong, and it affects only the things that root can do (like mounting?). Another issue is that qemu-5 doesn't build out of the box with virtfs. And I have another one too, we have never used it in the past.

It’s hard to determine, if it wasn’t used. At least it’s currently not used for the systems in /project/vm.

And as QEMU is used mainly by the administrators, which are able to become root, I’d vote for leaving the feature enabled – especially to avoid confusion.
This holds no longer true, since it's intended to release qemu to the users, giving them the option to do their own docker/apt install stuff (if they like).

That’s why I wrote mainly. ;-) There are quite a few examples of programs, where a subset of features requires root privileges, and we have that feature enabled.

Nevertheless, we should discuss in our group, what the merit of pkg-scripts is. In my opinion it has diverted from giving our scientists “reproducible development environments” (scripts).
The merrit was explained in the commit message, at least I thougt so. We can keep 'our' sensible qemu,

To my knowledge the policy with our machines is also to use the latest and greatest version. It just just gradually tested. I do not see, that we will ever be in a hurry to update QEMU versions to not have one or two days for testing it.

and users may use qemu3,4,5 all reproducible via the pkg/bla-version mechanism.

I just do not see, why users should want different versions of QEMU. It’s the point of virtualization to emulate the hardware, and the scientists do not care on what machine they execute their program, for example, if it has an AMD or Intel processor. So, the QEMU version is also irrelevant.

[donald]

I'd like to have multiple versions of qemu, because I'd like to be able to migrate a single vm to a new qemu version and run/test it for some time and than do other VMs one after the other until all are rolled over.