Bug 1525987

THe GNOME flatpak runtime environment provides a very minimal set of dependencies, and I don't think you can assume that virt-manager could use a libvirtd that's running outside the sandbox. Thus you would probably end up having to build libvirt (and most of its huge chain of dependencies) and bundling the whole lot in the flatpak. This would end up being a massive amount of work. The end result could be quite nice, but its not easy getting there.

I like the whole Flatpak idea. Anyway from the developer point of view Fedora Silverblue is not worth installing. If I can not simply install all of my tools (including virt-manager) on my workstation it simply forcing me to stick with the standard Fedora distribution.
Is Fedora Silverblue intended for Developers or standard/non-advanced users only?

You'll have to ask Silverblue devs about their target audience.

I don't think Dan was saying it's not worthwhile to try to flatpak-ify virt-manager, just that it'll take some work. So this is a valid request but unclear when it will be implemented

Daniel Berrange
> I don't think you can assume that virt-manager could use a libvirtd that's running outside the sandbox. Thus you would probably end up having to build libvirt (and most of its huge chain of dependencies) and bundling the whole lot in the flatpak. This would end up being a massive amount of work.

Gnome boxes currently exists as a flatpak, which has libvirtd inside of it:

https://www.flathub.org/apps/details/org.gnome.Boxes

So this is definitely doable.

In reply to  Ondrej Gajdusek:
>Anyway from the developer point of view Fedora Silverblue is not worth installing. If I can not simply install all of my tools (including virt-manager) on my workstation it simply forcing me to stick with the standard Fedora distribution.

I was able to install virt-manager as a layered package on Silverblue. There was one folder that I had to run restorecon on in order to get virtlogd able to run -- but aside from that, it works perfectly.
It's not ideal though -- the @virtualization stuff comes with a large number of dependencies -- I did briefly run into a conflict due to libguestfs-tools and python3-libguestfs causing a conflict due to requiring a different version of libdnf than what the ostree build used. Though, that was a fairly minor issue.

(In reply to jkliop from comment #4)
> Daniel Berrange
> > I don't think you can assume that virt-manager could use a libvirtd that's running outside the sandbox. Thus you would probably end up having to build libvirt (and most of its huge chain of dependencies) and bundling the whole lot in the flatpak. This would end up being a massive amount of work.
> 
> Gnome boxes currently exists as a flatpak, which has libvirtd inside of it:
> 
> https://www.flathub.org/apps/details/org.gnome.Boxes
> 
> So this is definitely doable.

If you look at the build logs you'll see the build has disabled a huge number of features in libvirt - it is about the most minimalistic build possible. This might be acceptable for Boxes since it uses a narrow set of functionality, but it will be a problem for virt-manager which users a broad set of functionality.

(In reply to Daniel Berrange from comment #5)
> If you look at the build logs you'll see the build has disabled a huge
> number of features in libvirt - it is about the most minimalistic build
> possible.

Doesn't look like this from the build manifest:

https://github.com/flathub/org.gnome.Boxes/blob/master/org.gnome.Boxes.json

        {
            "name" : "libvirt",
            "config-opts" : [
                "--without-html-subdir",
                "--without-storage-mpath"
            ],
            "sources" : [
                {
                    "type" : "archive",
                    "url" : "https://libvirt.org/sources/libvirt-4.1.0.tar.xz",
                    "sha256" : "8a2fa4826f311a936be8b7d4c8d76516c29417a593b1d1bb8641a8caaa316439"
                }
            ]
       },

If someone wants to send patches or jump on the mailing list to discuss trying to flatpak-ify virt-manager, I'm happy to discuss, provide reviews, etc.
But unless priorities change I don't think this is going to be implemented by the virt-manager dev team any time soon
Given that I'm not sure what use keeping this bug open is... I'll leave it alone for now though.

Here's a proof-of-concept Flatapk manifest, only briefly tested as I'm not a heavy user of VMs and I just started switching to libvirt.
https://github.com/tinywrkb/flatpaks/blob/master/org.virt_manager.virt-manager/org.virt_manager.virt-manager.yaml

There's no problem of accessing libvirt running on the host as Flatpak is directed to bind mount /run/libvirt and you can also use ssh, though I haven't configured the latter yet in libvirt with regards to spice/vnc permissions over ssh.

Note that I had a problem with libvirt not respecting runstatedir and uses instead the default localstatedir ($prefix/var/run => /app/var/run) for the default libvirt socket path so I had to set localstatedir=/var so uris like qemu:///system and qemu+ssh://localhost/system won't break in virsh and virt-manager.

I don't plan to publish this via Flathub but if anyone else wants to then he's welcome to start from my manifest.

tinywrkb Thanks for reporting your efforts!

However we are closing this bug tracker and moving to using github issues for upstream virt-manager bug tracking.

Presently I don't think any virt-manager devs have plans to natively provide a flatpak. Speaking for myself I don't have any plans, and don't expect this to change in the future.
A flatpak could be provided by someone outside the project though.

Tracking this in a bug probably won't change anything on virt-manager team side, but I understand it is a useful place for people to document their efforts like tinywrkb did.

I am closing this bug. If someone wants to report their progress on providing a virt-manager flatpak feel free to file an issue in virt-manager github