On Sun, Dec 15, 2019 at 1:21 PM Cole Robinson <crobinso@xxxxxxxxxx> 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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
