On Sun, Dec 15, 2019 at 1:21 PM Cole Robinson <crobinso(a)redhat.com> wrote:
On 12/14/19 10:24 PM, Tom Horsley wrote:
> I was reading all the reasons virt-fs is the superior way
> for virtual guests to share filesystems with the host. Then
> after all the hype I discovered it apparently wasn't in any
> released kernels or tools yet :-).
>
> Is it likely to appear in the fedora 32 or 33 time frame?
> Will there be GUI support for sharing with virt-fs
> in the virt-manager tool?
>
> Just curious. I'd like to experiment with it when I don't
> have to apply kernel patches and fiddle qemu command lines
> to do so :-).
AFAIK are already on track for f32 kernel and qemu. There's libvirt
patches that are working but they aren't in libvirt.git yet. Once they
are there it shouldn't be much more work to wire it up in virt-manager
UI. So Fedora 32 sounds right
Hi Cole,
I realize the primary use case is data sharing. Since the resulting
device won't appear as a virtual block device, it couldn't be used as
an OS installation target, at least not in the usual sense. But I
wonder if such a VM could use direct kernel boot, and everything else
goes in a dir or even a Btrfs subvolume? When I think about the
proposed systemd-homed using a LUKS encrypted file on loop mounted at
~/, and then the default Boxes behavior to create a qcow2 in ~/ -
that's three layers of file systems, potentially. I like the idea of
eliminating one or two of those, if there's a significant performance
advantage of virtio-fs over using either raw or qcow2 files.
--
Chris Murphy