Re: OVMF, lvm devices, and hvm guests

[Brad Spencer <brad%anduin.eldar.org@localhost>]

T <bobs%thelibertytree.org@localhost> writes:

> On Wed, 24 Aug 2022 15:17:59 -0400, Brad Spencer wrote:
>> Usually I like to use LVM raw devices for Xen guests rather than files.
>> So, I created a LVM LV that was exactly the same size as the file based
>> disk used in the previous section.  I then dd'ed the contents of the
>> file into the raw LVM LV and adjusted the guest config to the LVM LV
>> block device.  This does not work.  One of a couple of things happen:
>> 
>> 1) If the kernel actually boots up, it will not be able to find it root
>> filesystem and nothing that I put in telling it what that was helped.  I
>> had actually noticed before that I was unable to use the new qemu-dm
>> with old HVM guests and had to use use qemu traditional (and I think
>> RomBIOS) instead.  Those HVM guests had the same problem in that the
>> SeaBIOS could not find a bootable disk while the older qemu could.
>
> What path are you using in your HVM config? This is what mine looks like 
> for example:
> disk=[ '/dev/mapper/rvg0-NetBSD01,raw,sda,w' ]


To respond to this again with a bit more information...

[To recap some context ... I was mostly messing with using OVMF and UEFI
booting of a DOMU HVM guest when I wrote the original email]

If I have a disk image in /lhome/xen/disks/tc.disk and for the rest of
the context, this would be a image with GPT and a EFI filesystem along
with a FFS for the NetBSD root and use the following:

disk = [ '/lhome/xen/disks/tc.disk,raw,sda,w' ]

The above will work, that is the OVMF firmware is able to load the
NetBSD boot efi program and boot the OS and the OS is able to find its
root filesystem on a SCSI controller... If I take that EXACT same image
and put it into a LVM LV on a VG called notraidvg and an LV name of
tclv0 and use the following:

disk = [ '/dev/mapper/rnotraidvg-tclv0,raw,sda,w' ]

The above will hang up in the OVMF firmware and never attempt to boot.

From previous testing, I have also determined that MBR booting acts in a
simular manor with SeaBIOS often unable to find the boot block and/or
NetBSD unable to find its root filesystem if the image is on a LVM LV.
I did not try to replicate that again, as I didn't have a useful image
sitting around any more.  Further, and probably related, I had a couple
of ArchLinux HVM guests and with Xen 4.8 they booted fine.  When I
updated to Xen 4.15 they would not boot, with the usual problem I
started to see with SeaBIOS not being able to find the boot blocks.  I
switched to qemu traditional (ROMBIOS I believe) and they worked (and
have since been converted to PVH guests, so the HVMness is gone at this
point).  All of the disks used by these ArchLinux systems are LVM LVs.




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org