On Sunday, December 15, 2019 2:59:10 PM MST Chris Murphy wrote: > 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. Yeah, you could do direct kernel boot so long as your initramfs includes the module that provides virt-fs, and then specify your cmdline such that initramfs would mount virt-fs to /sysroot. Don't you mean two layers of filesystems? With systemd-homed, unless there's even more miscommunication with that than what came up on -devel within the past few weeks, I'd imagine that's using a partition or removable media as a block device for the LUKS container for the home directory? Regardless, it doesn't matter as much as you might expect. I used to think the same, but once your source file is opened from the filesystem, reads specifically are not all that slow, because its metadata will be cached. Looks like Boxes is a GNOME thing, does it give you an option to specify the location of the disks? If not, I'd recommend opening a bug report with GNOME. -- John M. Harris, Jr. Splentity _______________________________________________ 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