CasaOS-AppStore
CasaOS-AppStore copied to clipboard
Add ``Virtual Machine Manager`` to App Store (May Need Changes on Host)
This PR adds Virtual Machine Manager (virt-manager) which uses libvirt and QEMU/KVM to run virtual machines. It depends on having QEMU and libvirt on the host though, but this can easily be configured also to run it from the container itself by rebuilding it with QEMU and libvirt included. However, having those installed on the host is better for the best performance in the VMs that are being managed from the container. Also, it resolves conflicts. By making sure that it runs from the host, someone can also connect as client to QEMU from their own system (option to connect to remote libvirt server with QEMU over SSH on host). If we'd do this in the container, we need it to have a seperate IP from the host and it also needs to include SSH. This is not ideal, so it's better to have QEMU and libvirt on the host, mount the files for them to work in the container and connect to it. This keeps the GUI possibility of this container while also allowing the client to connect from their local Virtual Machine Manager app directly. The Docker image has the latest
tag though, but it's the only pushed tag. So I don't think this will cause conflicts in this case. It works for me from that tag. Is there a way we can also still hookup a script into this app to install QEMU and libvirt on the host? Or like add notes?
Hmm, the thing is that if I import this docker-compose, it reads nothing. Everything stays blank in CasaOS. Is it due to the formatting? If so, tell me what's wrong please.
I tried the manual one I made, and that one works! Going to try to change the old one to fit the working manual made app one
Thanks for your contribution. this PR is very awesome😉. But we need more test and internal discussion to merge it.🤔
Thanks for your contribution. this PR is very awesome😉. But we need more test and internal discussion to merge it.🤔
Yes, agreed. I need to make a few changes to the Docker Compose, since it doesn't seem correctly formatted or it has something to do with the order. Plus, I need to add a tip for before installing. I'll have to look into those things soon, and maybe you could help a bit to find the issue? Thanks in advance!
@CorrectRoadH I think I've fixed that validation issue now (I think it was due to the comments). So could you please approve the workflow again? Or even better, for now just keep it approved definitive (I'm not sure whether that's possible).
@CorrectRoadH I have seen the problems again now. Probably my formatting with the two x-casaos
was incorrect, causing this to happen. I have also correctly formatted the thing underneath the section. Could you approve it again for me and let it run?
I would still have to add the tip anyway also. Let me do that real quick.
@CorrectRoadH I have seen the problems again now. Probably my formatting with the two
x-casaos
was incorrect, causing this to happen. I have also correctly formatted the thing underneath the section. Could you approve it again for me and let it run?
Thanks for your contribution and feedback. I modified the workflow strategy to allow it run without approve. and I also help you to correct the docker compose yaml.
Tested on aarch64 and it doesn't work properly :(
At least in this compose file/var/run/libvirt/libvirt-sock
mount is missing.
And I don't know why virt-manager can't find aarch64 uefi binaries, even if I install it manually in the container using apt install qemu-efi-aarch64
Interface is pretty buggy, I can't even enter a distro name in the OS type section. Maybe
mber5/virt-manager
is not the best image or gtk3-broadway is poor solution for this.
Tested on aarch64 and it doesn't work properly :( At least in this compose file
/var/run/libvirt/libvirt-sock
mount is missing. And I don't know why virt-manager can't find aarch64 uefi binaries, even if I install it manually in the container usingapt install qemu-efi-aarch64
Interface is pretty buggy, I can't even enter a distro name in the OS type section. Maybe
mber5/virt-manager
is not the best image or gtk3-broadway is poor solution for this.
I see, maybe something with the aarch64 version is just odd. The x86-64 version has all of this working fine, and it's not buggy. I tested it on a server with even an old Intel Core i3-2100, works fine. I guess I may need to fork the Docker image and make some changes to make it work, and/or open a pull request (since the image is also on GitHub).
Docker Compose file seems to be correct now. Still yet it's not working when I test it on a CasaOS instance with Debian 12 (or 13 beta, not sure). Except that it now seems correctly formatted. Once we get the other things fixed it should be ready to be merged, I think?
Tested on aarch64 and it doesn't work properly :( At least in this compose file
/var/run/libvirt/libvirt-sock
mount is missing. And I don't know why virt-manager can't find aarch64 uefi binaries, even if I install it manually in the container usingapt install qemu-efi-aarch64
Interface is pretty buggy, I can't even enter a distro name in the OS type section. Maybe
mber5/virt-manager
is not the best image or gtk3-broadway is poor solution for this.
I think it didn't add the mount properly either when importing the Compose.
Tested on aarch64 and it doesn't work properly :( At least in this compose file
/var/run/libvirt/libvirt-sock
mount is missing. And I don't know why virt-manager can't find aarch64 uefi binaries, even if I install it manually in the container usingapt install qemu-efi-aarch64
Interface is pretty buggy, I can't even enter a distro name in the OS type section. Maybe
mber5/virt-manager
is not the best image or gtk3-broadway is poor solution for this.
~~Ah also, I thought that setting the libvirt directory on the host to the guest would also passthrough the sock. Maybe I should pass it through directly as file plus the directory, to guarantee it.~~
Nope, I changed it to /var/lib/libvirt, which doesn't contain the sock and so I know the issue probably. Will now fix it @sund3RRR.
@sund3RRR Done! Could you try it again and let me know the results? Try the one from the newest commit.
@sund3RRR Done! Could you try it again and let me know the results? Try the one from the newest commit.
Yes, qemu connection now works 👍
I don't know I ran into a really weird issue. For some reason, keyboard works in shortcut mode in my case. I can't select any OS like debian, ubuntu, nixos, arch, fedora. I recorded a small demonstration of this bug. https://disk.yandex.ru/i/I40JPYD8s-KqAA I'm very concerned about the quality of this docker image. Don't get me wrong, I just don't want to people run into the same error and think it is a CasaOS problem. I think if we submit an app to the store, it should work perfectly. Maybe cockpit is better solution? At least it is a webUI without buggy and blurry gtk-broadway. It is just my opinion.
I don't know I ran into a really weird issue. For some reason, keyboard works in shortcut mode in my case. I can't select any OS like debian, ubuntu, nixos, arch, fedora. I recorded a small demonstration of this bug. https://disk.yandex.ru/i/I40JPYD8s-KqAA I'm very concerned about the quality of this docker image. Don't get me wrong, I just don't want to people run into the same error and think it is a CasaOS problem. I think if we submit an app to the store, it should work perfectly. Maybe cockpit is better solution? At least it is a webUI without buggy and blurry gtk-broadway. It is just my opinion.
That blurry thing may be normal. The other isn't. I think this image doesn't have a good aarch64 architecture Docker image. Works fine with the x86 version for me. I can also try recording now.
@sund3RRR
Perhaps should make a note that arm64 image is experimental or broken. I want to say broken, it is funny issue, i can navigate on window like vim hjkl mode.
@sund3RRR
2024-05-18.12-04-05.mp4
How did you setup code server? Native or docker container? I realize that container solution is not comfortable for code server because if you make changes in rootfs, it will be missed after restart because docker doesn't save state.
@sund3RRR 2024-05-18.12-04-05.mp4
How did you setup code server? Native or docker container? I realize that container solution is not comfortable for code server because if you make changes in rootfs, it will be missed after restart because docker doesn't save state.
Off-topic but I don't know, it's my friend's server where I have access to. She'd set it up.
@sund3RRR 2024-05-18.12-04-05.mp4
How did you setup code server? Native or docker container? I realize that container solution is not comfortable for code server because if you make changes in rootfs, it will be missed after restart because docker doesn't save state.
Off-topic but I don't know, it's my friend's server where I have access to. She'd set it up.
I also have it now. It keeps the stuff fine. It depends on the location and maybe the permissions. Installing things using a package manager will be discarded at the next start of the container, but things for my workspace are kept and everything related to Visual Studio Code.
@CorrectRoadH Anything wrong with my syntax? It still doesn't work with mine when importing this current Compose file manually, works when making manually or with another Compose of here (JellyFin and JDownloader2 work at least, probably every single one that it's official and on the main repository right now).
@CorrectRoadH Anything wrong with my syntax? It still doesn't work with mine when importing this current Compose file manually, works when making manually or with another Compose of here (JellyFin and JDownloader2 work at least, probably every single one that it's official and on the main repository right now).
Thank you for your contribution. I will help you modify docker compose yml to work. But I don’t have enough mental bandwidth lately😂. So I get to deal with it a few days later.
@CorrectRoadH Anything wrong with my syntax? It still doesn't work with mine when importing this current Compose file manually, works when making manually or with another Compose of here (JellyFin and JDownloader2 work at least, probably every single one that it's official and on the main repository right now).
Import failed because of this line:
DARK_MODE: false
Maybe something wrong with casaos compose parser. If you wrap boolean like this:
DARK_MODE: "false"
It will work
@CorrectRoadH Anything wrong with my syntax? It still doesn't work with mine when importing this current Compose file manually, works when making manually or with another Compose of here (JellyFin and JDownloader2 work at least, probably every single one that it's official and on the main repository right now).
Is the VM work in your computer?🤔
It's not work in My CasaOS
@CorrectRoadH Anything wrong with my syntax? It still doesn't work with mine when importing this current Compose file manually, works when making manually or with another Compose of here (JellyFin and JDownloader2 work at least, probably every single one that it's official and on the main repository right now).
Is the VM work in your computer?🤔
It's not work in My CasaOS
Worked for me on my friend's server (can't really test it well on my own server since it already runs in a container and the host works different). Seems like permission issues?
Thanks for your contribution.🥳