Anyone knows how to setup kvm/libvirt to boot a VM directly from an LVM partition containing a filesystem?
I just want the host to load the latest kernel + initrd from the root filesystem of the VM without the need for a DOS partition table, an MBR to load GRUB, etc.
And if the solution starts with "create a GPT and a UEFI boot partition", then I'm happy to keep the MBR.
What I'm looking for is to simplify VM disks down to a plain filesystem hosted in an LVM logical volume. Now I have this DOS/GPT disk nonsense that can't be mounted on the host without special magic.
cc: @benoit @angristan
@codewiz
a) grub2 can "in some cases" write an MBR which can boot kernel/initrd from LVM. It's not stable enough for us to support it in RHEL, we closed the feature request "boot from LVM without boot partition".
b) you can host kernel/initrd completely external, i.e. make it available via PXE
c) Try to have qemu-kvm use kernel directly. You would then open the LVM from the host, and use "qemu-kvm -kernel -append -initrd [..".
c) looks best, share how it goes.
@benoit @angristan
@globalc @codewiz @benoit @angristan I wonder if this can also be done with a separate Grub disk image that boots the main one. (Not that @codewiz said why a single LVM part was needed!).
@penguin42
If I recall the issues correctly, that might work. IIRC, the issue for grub2/lvm/mbr here is that it needs to embed a bitmap of the places on the disk where kernel/initrd are stored, and there is not enough space for that bitmap in all cases.
@codewiz @benoit @angristan
@globalc @penguin42 @benoit @angristan @srevinsaju I think it was LILO having a bitmap to find the blocks where the kernel and initrd were stored on the disk.
GRUB1 used the "MBR DOS compatibility gap to store its "stage 1.5", which was able to decode the ext filesystem enough to load the stage 2 which would then load the config and bring up the menu.
@globalc @penguin42 @benoit @angristan @srevinsaju I can't find where it's documented, but I think that GRUB2 installs a lot of stuff in the huge gap left by fdisk or gdisk to align the first partition to 2048 cylinders. This is how GRUB2 can boot from a RAID5, LUKS-encrypted, LVM partition.
@globalc @penguin42 @benoit @angristan @srevinsaju On UEFI systems, GRUB2 places an EFI binary in the EFI system partition, which is just a DOS filesystem. If there's "secure" boot, there's a shim bootloader signed by Microsoft which loads the GRUB EFI file after verifying it somehow.
I don't know how you'd make the DOS partition work with software RAID1. If you can't, this would make all UEFI servers vulnerable to a single disk failure, which is bad.
@globalc @penguin42 @benoit @angristan @srevinsaju As you might have guess, I'm not a big fan of UEFI, GPT and secure boot. I think they introduce a ton of unnecessary complexity to support a chain of trust leading to Microsoft's "Trusted Computing" dream, where all PCs sold on the market will only boot a "genuine" operating system authorized by Microsoft.
@codewiz
Can't say that I'm happy with Microsoft being the ones who sign, but that is anyway just used as "the standard", so OEMs know which CA-cert they should ship.
One can enroll own keys in the firmware and untrust the Microsoft one. Some OEMs also by default ship an own CA-cert they trust with their systems, next to the Microsoft one.
@penguin42 @benoit @angristan @srevinsaju
@globalc @codewiz @benoit @angristan @srevinsaju Eek I think I'd worry more about the OEM certs; my main problem with a lot of the UEFI setups is the OEM provided bugs; like the ones that lose the boot order, or always hunt for a windows installation.
@penguin42 @codewiz
At least one can remove the certs the system is trusting.
Besides rolling out own certs, some firmwares also allow something like "trust code with this hash".
These things can be nicely tried out nowadays, KVM can now deal with secure boot.
I started to write an article on secure boot and emulation, own certs some months ago but got stuck.
@penguin42 @globalc @codewiz ovmf secure boot with KVM and a vtpm works, and I use it all the time for testing UEFI stuff, although it doesn't really provide any additional protection against attackers. Typically I tftp the kernel+initrd as a signed EFI executable instead of messing around with GPT.
