Add QEMU
Delta2Force opened this issue · 27 comments
QEMU can be accessed using a VNC server, which shouldn't be too hard to implement. QEMU exists for all platforms, so it should work pretty well. I would add an option at the start to use VirtualBox or QEMU.
I have a new idea about doing qemu alltogether: what about turning QEMU into a JNI library and just calling all the functions directly within the mod? I'm looking into this right now, but it should be possible.
@Delta2Force I may have found something that could help:
https://stackoverflow.com/questions/18414441/making-a-connection-to-qemu-with-libvirt-java-api
https://libvirt.org
https://gitlab.com/libvirt/libvirt-java
I wonder if the implementation of a real VNC client for the ingame screen means that it will be able to connect to any remote stream over the network (not only on the local PC).
If so, would it be possible for the server running the game to also be running many VMs with Vbox or Qemu/KVM, all managed by this mod through APIs like libvirt in case of Qemu and Vbox API?
That would be awesome if @Delta2Force is able to do that, and it could also kinda help with #3
I'm currently working on this, you can watch my progress on the qemu branch.
I've got the setup GUI (the one when you start the game) working with QEMU, I've only tested it on Linux yet though and I will test it using Windows later on (before publishing the version). The rest of the implementation should be incredibly simple, just connect to the screen using VNC and get a feed in VMRunnable, create VHDs using the qemu command, start the VM by creating a long command, stop it by just killing the process, maybe I can detect if it's manually shut down if the process stops on it's own, and it should be all set by then.
I know that QEMU has multiple architectures, which ones are you going to support?
I wonder if the implementation of a real VNC client for the ingame screen means that it will be able to connect to any remote stream over the network (not only on the local PC).
If so, would it be possible for the server running the game to also be running many VMs with Vbox or Qemu/KVM, all managed by this mod through APIs like libvirt in case of Qemu and Vbox API?
Theoretically, yes! It would be a really cool idea. For it to work cables would have to be added first though, so different PCs can have different screens and such.
I'm currently working on this, you can watch my progress on the qemu branch.
I've got the setup GUI (the one when you start the game) working with QEMU, I've only tested it on Linux yet though and I will test it using Windows later on (before publishing the version). The rest of the implementation should be incredibly simple, just connect to the screen using VNC and get a feed in VMRunnable, create VHDs using the qemu command, start the VM by creating a long command, stop it by just killing the process, maybe I can detect if it's manually shut down if the process stops on it's own, and it should be all set by then.
https://blogs.oracle.com/vaibhav/listing-java-process-from-java
https://www.baeldung.com/java-process-api
Ok, currently the input is a bit weird. I don't have a clue how to solve it other than maybe using a different VNC library. You can try it out by compiling the qemu branch.
I have tried building and using Qemu, i think it works, but it seems i have no display , and no way to know which port are used for vnc (or even if vnc is working)
I built mod using Gradle from JetBrains Idea 2020
System: Arch KDE, linux-5.7.12-arch1-1, qemu 5.0.0-8
Java 11, changing Java to either openjdk-8 or oracle-jre 8 does not help ( it even crashes game when right clicking on screen )
Minecraft log
@Meister1593, the VNC Server is "localhost:1", You can see it from the process info like you did (just after the QEMU executable file).
@Delta2Force, QEMU starts and works if you connect manually to it (via a VNC Viewer program). The input from the game doesn't work at all (black screen and no input passes from the game to QEMU/VNC)
@Meister1593, the VNC Server is "localhost:1", You can see it from the process info like you did (just after the QEMU executable file).
@Delta2Force, QEMU starts and works if you connect manually to it (via a VNC Viewer program). The input from the game doesn't work at all (black screen and no input passes from the game to QEMU/VNC)
I tried using vnc viewer with this ip:port and it worked! Though, it's quite slow, even Arch iso was loading like 5 mins, which is really slow. I shared 8 gigs of ram and cpu divided by two (6 threads), usually it starts in less than 1 min in VirtualManager (qemu).
Input from game crashes my game btw. Log
I did some research and coding about this implementation and found some things:
- Enabling KVM greatly increases performance, like radically. (from 3-5 mins loading of arch down to 30-60 seconds)
- No keymap for lower case characters (which is fine since we send capslock? maybe? (not really, works 50/50) i implemented lowercase check for this and it works always).
- For some unknown reason, when you first use screen everything is fine, then if you use it again, all characters you type does not work properly , keysums and etc does not change, it seems something wrong with vernacular, but i've not checked whole code about input handling.
- To use mod every time you rejoin world, you have to break screen and place it again (or place another screen)
- I've changed graphics to virtio and it solved problem with freezing screen, but this needs additional checking.
- Updating keymaps and cursor through VMRunnable is terrible idea since it's very slow, very unnatural feeling when trying to type or move cursor.
- What IDE guys are you using? Intellij Idea making warnings about NPE, cases where some stuff is overcomplicated or just not needed (default values and generic types), wrong indentation. Allover the project.
Sadly, i haven't found any java vnc library except ones that uses C mappings (JNA)
Basically issue with input was: unfocusing from screen caused keys about unpressing not to be added to vnc keys scheduler.
I've uploaded timer-based fix with other stuff too, this is not over yet with issues)
Can you do a pull request on here with your changes?
I wasn't sure about making pull request since it's not all fixes, but if you said about it, then sure i will make it.
Generally speaking, there is a need a centralized handling for all input, no matter from where. Else somewhere you would handle input using GLFW directly in one render frame, and in other you would process it using mixin, this causes issues, as you can see with GuiFocus and VMRunnable.
I did some fixes and changes, but i found other bugs...
Linux mint or any other distro with UI launch 50/50 times and when they launch, they don't appear to update GUI on screen at all, or at least when i try to interact with screen, it doesn't move mouse or press any button (in vnc they're fine).
EDIT: I found the root of problem, it was input handling in VMRunnable. I will try to make input handling better, since it's very slow
I just noticed this:
Does it still start the VM if KVM is disabled or it's launched using Windows?
I just noticed this:
Does it still start the VM if KVM is disabled or it's launched using Windows?
I don't have Windows right now, and it probably won't start without KVM.
Not sure if windows includes it by default or you have to enable it, but this specific command about kvm should be checked for available kvm before adding it.
Note: this gives a huge boost in performance, so disabling it would kill any reason to use QEMU.
Maybe there's alternative solution (like hyper-v, not sure if qemu supports it), but this is what i just noticed on most qemu tutorials
Currently the QEMU to display output and input handling is very slow and there's always a chance for freezed screen.
Most likely because of conversions of bytestreams to array of bytes and nativeimage, and all of this in two completely different parts of code.
Basically everything but qemu works real slow
I have a new idea about doing qemu alltogether: what about turning QEMU into a JNI library and just calling all the functions directly within the mod? I'm looking into this right now, but it should be possible.
I have a new idea about doing qemu alltogether: what about turning QEMU into a JNI library and just calling all the functions directly within the mod? I'm looking into this right now, but it should be possible.
isn't this gonna be kinda madness taking care of such huge thing as making qemu adapter for JNI?
Virtualbox had it's own library for java, but qemu? Sounds really big.
Anybody say Cables? #37
I just noticed this:
Does it still start the VM if KVM is disabled or it's launched using Windows?
I don't have Windows right now, and it probably won't start without KVM.
Not sure if windows includes it by default or you have to enable it, but this specific command about kvm should be checked for available kvm before adding it.
Note: this gives a huge boost in performance, so disabling it would kill any reason to use QEMU.
Maybe there's alternative solution (like hyper-v, not sure if qemu supports it), but this is what i just noticed on most qemu tutorials
You can use Intel HAXM with QEMU on Windows to greatly improve performance (Intel processors only, I'm pretty sure AMD has something similar too, but the mod would have to recognize if the CPU is Intel or AMD and use the correct driver)
Edit: I did a quick Google search and I couldn't find AMD's equalivent to Intel HAXM driver (Android studio has their own driver but I don't think that would work). You can still use HAXM on Intel processors but for AMD you should either stick with VirtualBox or add Hyper-V support (#144 )
Edit 2: I just found out you can use Hyper-V with QEMU on Windows using the -accel whpx argument (requires Hyper-V and Windows Hypervisor Platform feature installed)