On Sun, Dec 15, 2019 at 5:09 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > 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? The PR and the PDF presentation, the three options are: 1. Plain dir or subvolume (no encryption) 2. Per user homes, i.e. ~/ not /home, encrypted using fscrypt(), right now this means a hard requirement on ext4 3. Per user homes, i.e. ~/ not /home, encrypted LUKS2 file mounted on loop device, this is the preferred/recommended workflow because it's straightforward to make the user home portable, by dropping it on a USB stick. Btrfs, ext4, XFS are supported. In the case of #3 you've got plausibly three file systems: A. /home - ostensibly the same as system root, but that's not required. B. ~/ - LUKS encrypted file on loop mount C. VM filesystems, inside the qcow2 file that's located somewhere in ~/ It's early days, still in code review, and hasn't been merged yet. > > 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. GNOME Boxes's target audience is minimal configuration, highly accessible to regular users. It's not a virt-manager replacement. While it is managed by libvirtd and thus you can use virsh to edit the configuration by CLI, since Boxes runs under the user, it doesn't have permissions to write to /var so the backing file gets stored in I think ~/.var or maybe ~/.local/share - I forget. Whereas virt-manager runs as a privileged process and its images go in /var and can't go anywhere in ~/ -- 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
