liliumstar@lemmy.dbzer0.com
on 18 Jan 07:38
nextcollapse
I would use the native version. For something like this, it makes sense that it should have less restricted/sandboxed access to the underlying system.
alteredEnvoy@sopuli.xyz
on 18 Jan 09:00
nextcollapse
Hmm, wouldn’t the virt manager just be a frontend and communicate with the virtd socket though?
deadcade@lemmy.deadca.de
on 18 Jan 11:29
nextcollapse
virt-manager only requires access to the libvirtd socket, as long as the flatpak.has that as default configuration (which I imagine would be the case), there’s zero difference beteween flatpak and native.
that is a good point… I obviously missed that. my generally would only use flatpak from the same developer of the app, or I will just use the deb packaged by my distro.
If you install virt-manager on Debian via apt it will have full system acres and also automatically install and configure libvirt, so this method is preferred.
boredsquirrel@slrpnk.net
on 18 Jan 13:02
nextcollapse
I recommend using a QEMU guest session with libvirt. This works in both versions.
The standard session requires root, and for some reason this means that VMs couls harm your system more or something
Guest sessions are usable within Flatpaks, GNOME boxes has a Flatpak too. Is the virt-manager flatpak from Flathub? Fedora had one before.
Pretty cool, on debian you may want to use that to get newer versions. Even though virt-manager is pretty slow in updates
The standard session requires root, and for some reason this means that VMs couls harm your system more or something
VMs don’t have access to the host, so even if the virtual machine emulator Qemu and libvirt require root access, the encapsulated guest virtual machine have no access to the host. They can’t harm your system.
Yup VMs dont get access to the system. Unless there is a vulnerability.
For doing malware testing etc, qemu user sessions might be preferred.
You can just use RPM/DEB virt-manager and switch to the QEMU user session anyways. If you dont need some advanced stuff like GPU passthrough (I guess) (USB works) you can use that full time. I do.
that_leaflet@lemmy.world
on 18 Jan 13:26
nextcollapse
The virt-manager flatpak doesn’t work out of the box, you need to do some setup on the host. At that point you may as well use the deb of virt-manager.
BananaTrifleViolin@lemmy.world
on 20 Jan 22:44
collapse
Depends on what distro you’re on? You say the deb version is 4.0 and flatpak is 5.0, suggesting you may be on a long release distro?
I’d favour the Deb version as it’s official for your distro. The flatpak version is unverified; it’s extremely unlikely Virt-Manager is compromised or will cause any issues but virtual machines do have security risks.
Also problem solving issues with the flatpak version may be more difficult as you have a whole layer potential issues in the sandbox on top of all the other issues people can have around KVM/QEMU. But you could install it, if it works great, if not, revert to the Deb version.
threaded - newest
I would use the native version. For something like this, it makes sense that it should have less restricted/sandboxed access to the underlying system.
Hmm, wouldn’t the virt manager just be a frontend and communicate with the virtd socket though?
virt-manager only requires access to the libvirtd socket, as long as the flatpak.has that as default configuration (which I imagine would be the case), there’s zero difference beteween flatpak and native.
actually there is difference in version between the two. deb by my distro is in 4.0.0 (mar, 2022) while flatpak is 5.0.0 (nov, 2024)
In my experience, this is not the case. It just says it can’t connect. Doesn’t specify how or where to.
i am not sure which one is the native version… you mean the version packaged by the distro (deb) or the developer (flatpak)?
In this case I meant the one packaged by your distro.
.
Is there now a flatpak for virt-manager?
I assume its this one: flathub.org/apps/org.virt_manager.virt-manager but its unverified and not directly from the actual developers.
Also seems to have way too many permissions. Maybe to work around some problem "flatpak"ing virt-manager?
that is a good point… I obviously missed that. my generally would only use flatpak from the same developer of the app, or I will just use the deb packaged by my distro.
If you install virt-manager on Debian via apt it will have full system acres and also automatically install and configure libvirt, so this method is preferred.
I recommend using a QEMU guest session with libvirt. This works in both versions.
The standard session requires root, and for some reason this means that VMs couls harm your system more or something
Guest sessions are usable within Flatpaks, GNOME boxes has a Flatpak too. Is the virt-manager flatpak from Flathub? Fedora had one before.
Pretty cool, on debian you may want to use that to get newer versions. Even though virt-manager is pretty slow in updates
VMs don’t have access to the host, so even if the virtual machine emulator Qemu and libvirt require root access, the encapsulated guest virtual machine have no access to the host. They can’t harm your system.
Yup VMs dont get access to the system. Unless there is a vulnerability.
For doing malware testing etc, qemu user sessions might be preferred.
You can just use RPM/DEB virt-manager and switch to the QEMU user session anyways. If you dont need some advanced stuff like GPU passthrough (I guess) (USB works) you can use that full time. I do.
The virt-manager flatpak doesn’t work out of the box, you need to do some setup on the host. At that point you may as well use the deb of virt-manager.
Depends on what distro you’re on? You say the deb version is 4.0 and flatpak is 5.0, suggesting you may be on a long release distro?
I’d favour the Deb version as it’s official for your distro. The flatpak version is unverified; it’s extremely unlikely Virt-Manager is compromised or will cause any issues but virtual machines do have security risks.
Also problem solving issues with the flatpak version may be more difficult as you have a whole layer potential issues in the sandbox on top of all the other issues people can have around KVM/QEMU. But you could install it, if it works great, if not, revert to the Deb version.