QEMU - users requesting versions later than 3.1

Deployment: Please indicate if you are either using EaaSI’s managed service (hosted.eaasi.cloud) or self-hosting; if the latter, please provide some basic detail of your computing setup if possible (cloud service, local VM, bare metal, etc.)


EaaSI Version (if self-hosting): This corresponds to the release branch/installer version used to deploy your server. This information should be available in the Manage Node menu, if accessible

Browser: The name and version of the browser you are using to access the EaaSI UI, if applicable

Description: Please describe your issue in as much detail as possible, including name + ID of any relevant environments, software or content. You can also attach screenshots or relevant error report files.

Some users have requested later versions to what is available right now, QEMU 2.12 and QEMU 3.1.

Thank you

Are you able to reproduce the issue or did it happen once? What steps can you take to repeat the issue? What did you expect to occur and what was the actual outcome?

Urgency: If possible, please give an indication of how urgently the issue needs to be addressed - is there a timeline or deadline (e.g. upcoming demo, researcher request, etc.) that EaaSI support staff should be aware of?

Not urgent.

Hi @Cynde_Moya! @rafaelgieschke is currently on vacation until next Monday (Sep. 4) but we’ll ping him when returns as to whether there are stable/compatible containers in the EaaS Docker registry with more recent QEMU versions.

Is there a specific feature users are looking to take advantage of? I know part of the issue currently with creating the Docker containers is the work needed to map changes in the emulator(s) to features and changes in the EaaS framework, so it map help to narrow down the question.

In principle, you should (should as in “untested” :grinning:) be able to use the “screamer” fork (based on QEMU 7.1.94) from QEMU-based MacOS 9.2.1+ operating systems have no sound, audio not supported - #2 by ethan.gates for other QEMU architectures (e.g., x86(-64)) as well. The same caveats would apply, i.e., you have to enable “WebRTC Audio (Beta)” and “XPRA Video (Experimental)” and specify -audiodev pa,id=pa,server=/emucon/data/sockets/pulse-iosocket as “nativeConfig”.

For a more general solution, the problem is that emulator support is currently hardcoded into eaas-server (for specific versions of emulators as their configuration might change between versions, this is why you are required to manually set -audiodev pa ... via nativeConfig in the example above). We do have plans to decouple the emulator implementation from eaas-server (as presented at iPres last year, though the ideas there are slightly outdated: https://doi.org/10.17605/OSF.IO/XEYR3) but have not implemented this yet due to other priorities.