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