Chris Laprise: > On 03/05/2017 08:11 AM, sm8ax1 wrote: >> >> Thanks, I read the custom install page prior to installing, but I was >> unaware of #2340. >> >> To be honest, when I decided I wanted BTRFS, I just sort of assumed that >> guest disk images were logical volumes to begin with. The custom install >> page mentioned LVM in every scenario, so I thought it was necessary for >> that reason. And the Xen wiki repeatedly mentions that logical volumes >> are faster than image files on any kind of filesystem. It was, however, >> suspcious when the custom install page said "-l 100%FREE" for the root >> LV. I guess that's what I get for assuming. >> >> Are there any plans for hooking Qubes up to the LVM in this way? LVM >> itself supports block-level rw CoW snapshots, and the Xen project >> strongly recommends it over image files. > > Normally you shouldn't mix Btrfs with LVM, as the former is a kind of > volume manager in itself. > > I have used Btrfs on Qubes for probably close to 2 years and it has been > very good in terms of stability and performance. However, anaconda > (fedora's installer) doesn't handle a mixture of partitioning and fs > options well, esp. if you select Btrfs. The only 'good' way I've found > is to select a Btrfs system install and let it re-partition the whole > disk; otherwise, it has a tendency to forget steps such as LUKS > encryption layer. > > Note that thin-provisoned LVM (probably the type you're referring to) > incurs a speed penalty as well. Its really doing the same work as Btrfs, > but without some of the nice features.
The installer worked the way I wanted it to after a few tries, as I mentioned earlier. I just had to delete the filesystem from the LV first. The custom install page even warns that it's likely to be glitchy. I can't really complain. I'm not sure what you mean by the installer forgetting the LUKS encryption layer. That already existed on the disk before I used the installer. I had to unlock it within the installer before I could setup the root and swap LVs. If it were to overwrite the whole LUKS container with a root filesystem then that's one hell of a bug. About Btrfs... You have a point that Btrfs can replace LVM for the most part and thin-provisioned LVM's performance is probably comparable. However, I was referring specifically to Xen Project's recommendation to use LVM because the block device backend is faster than the filesystem backend according to them. This is regardless of the performance difference between btrfs and thin-provisioned LVM, presumably. I mistakenly implied that snapshot capabilities even matter with things as they are today. If Qubes can run on ext4, necessarily without any CoW/snapshot infrastructure, then it seemingly could run on traditional LVM just the same. The only difference is it would be running on a block device rather than a filesystem. Snapshots and thin-provisioned LVM are both beyond the scope of this comparison. As a separate issue, CoW copies of blocks being created when a file is randomly written to is just part of how Btrfs works and irrelevant to snapshots (which AFAIK aren't used) in Qubes's case. It can cause bad performance with random-write scenarios like virtual machine images. Using an LV solves the problem, but so does `chattr +C`, so there's not much of an argument here. As an aside, sometimes the biggest advantage to using LVM is because many early userspace implementations don't know how to unlock multiple LUKS partitions (e.g. root (btrfs) and swap). Although you don't technically need swap unlocked in early userspace, you do if you want to resume from hibernation and/or only enter your password once. Btrfs doesn't support swap files either. Using Btrfs instead of LVM is completely valid in many cases. The question is whether the performance advantage of traditional LVM would justify supporting it in addition to image files. >> I wanted to setup MAC address spoofing on my wireless interface too, so >>>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when >>>> I restarted it my changes were gone. I read that I have to make changes >>>> in the TemplateVM itself (fedora-23) for them to be persistent, but the >>>> problem is that I don't necessarily need all VMs to have this change. >>>> I'm still not sure of the correct way to make changes to a single VM >>>> that inherits from a TemplateVM. >>> >>> On MAC anonymization: >>> >>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >> That's more or less what I read on other sites. I think we should >> consider putting a Big Fat Warning on that page saying that your changes >> will be lost on restart if the VM belongs to a template, or you could >> easily leak your real MAC address by accident. > > This behavior is explained in Qubes introductory material... > template-based VMs forget anything that isn't in /rw (such as home/). > That's why its routine for Qubes docs to instruct adding settings to the > template. In this case, the doc also has the user restarting the netVM > before checking the MAC address. > > Also, a given template does boot differently depending on the VM type > (netVM, proxyVM, appVM) that's using it. So Network Manager settings > don't really affect appVMs since they aren't intended to run NM. This is an interesting point I wasn't aware of. Are there more details on the specific differences between types of VMs? I guess I could have just made the changes to the fedora-23 TemplateVM then. >>> On TemplateVM persistence: >>> >>> https://www.qubes-os.org/doc/templates/#important-notes >>> >>> On making directories persistent without making the changes in a >>> TemplateVM: >>> >>> https://www.qubes-os.org/doc/bind-dirs/ >> Thanks. It sounds like bind-dirs.sh is just what I need! > > There are several alternatives for configuration. The VPN doc describes > using /rw/config (without bind-dirs) to configure and script things for > a specific VM. You could also create a standalone netVM so that config > changes become very straightforward. It depends on the specific case. > > Chris > Thanks. I went with bind-dirs.sh so far, but I'll look into the /rw/config method as well. I thought about creating a standalone VM at first, but having to update it separately is a disadvantage there. Like you said, it depends on the case. ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/32f2a406-4f84-7e5d-85d4-23c9f8d10450%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
