ovirt VM image to BM
Greetings masters, I got pointed to you guys as experts on smtg I'm struggling with. I'm trying to move an ovirt vm raw image to a bm machine and though I could do it successfully using dd (got able to see and work with the partitions and the data fine), I couldn't boot the disk. It may be an issue with drivers (like the virtio drivers), but idk, and I'm wondering if someone has done smtg similar or could help somehow with the process. Really appreciate any answer on that, thanks! Gui
On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote:
Greetings masters,
I got pointed to you guys as experts on smtg I'm struggling with. I'm trying to move an ovirt vm raw image to a bm machine and though [bm = baremetal] I could do it successfully using dd (got able to see and work with the partitions and the data fine), I couldn't boot the disk.
It may be an issue with drivers (like the virtio drivers), but idk, and I'm wondering if someone has done smtg similar or could help somehow with the process.
So in IRC we established that it's a RHEL 8.6 guest, and that it doesn't get as far as grub. The virtual machine boots with UEFI and the physical machine boots with BIOS which is why grub doesn't work. Conversion of a machine from UEFI to BIOS is usually quite tricky. Are you sure the baremetal machine doesn't support UEFI booting? Almost anything made in the last 10 years should, although you may have to adjust the firmware ("BIOS") configuration. After that it'll probably not have the right drivers in the initramfs. Symptoms would be that it gets to grub, then boots the kernel, but fails when mounting the root filesystem. Luckily this is easier to solve - identify which drivers are needed for the target hardware and before copying across, run “dracut --add-drivers ..” You'll have to read the dracut man page closely. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Wed, May 18, 2022 at 01:56:36PM +0100, Richard W.M. Jones wrote:
On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote:
Greetings masters,
I got pointed to you guys as experts on smtg I'm struggling with. I'm trying to move an ovirt vm raw image to a bm machine and though [bm = baremetal] I could do it successfully using dd (got able to see and work with the partitions and the data fine), I couldn't boot the disk.
It may be an issue with drivers (like the virtio drivers), but idk, and I'm wondering if someone has done smtg similar or could help somehow with the process.
So in IRC we established that it's a RHEL 8.6 guest, and that it doesn't get as far as grub. The virtual machine boots with UEFI and the physical machine boots with BIOS which is why grub doesn't work.
Conversion of a machine from UEFI to BIOS is usually quite tricky. Are you sure the baremetal machine doesn't support UEFI booting? Almost anything made in the last 10 years should, although you may have to adjust the firmware ("BIOS") configuration.
After that it'll probably not have the right drivers in the initramfs. Symptoms would be that it gets to grub, then boots the kernel, but fails when mounting the root filesystem. Luckily this is easier to solve - identify which drivers are needed for the target hardware and before copying across, run “dracut --add-drivers ..” You'll have to read the dracut man page closely.
Update is that after changing the hardware to use UEFI it booted all the way (a little surprising?) But the keyboard doesn't work. This is also surprising because I *thought* that both virt and baremetal basically use emulated or real USB keyboard these days. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On 05/18/22 15:30, Richard W.M. Jones wrote:
On Wed, May 18, 2022 at 01:56:36PM +0100, Richard W.M. Jones wrote:
On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote:
Greetings masters,
I got pointed to you guys as experts on smtg I'm struggling with. I'm trying to move an ovirt vm raw image to a bm machine and though [bm = baremetal] I could do it successfully using dd (got able to see and work with the partitions and the data fine), I couldn't boot the disk.
It may be an issue with drivers (like the virtio drivers), but idk, and I'm wondering if someone has done smtg similar or could help somehow with the process.
So in IRC we established that it's a RHEL 8.6 guest, and that it doesn't get as far as grub. The virtual machine boots with UEFI and the physical machine boots with BIOS which is why grub doesn't work.
Conversion of a machine from UEFI to BIOS is usually quite tricky. Are you sure the baremetal machine doesn't support UEFI booting? Almost anything made in the last 10 years should, although you may have to adjust the firmware ("BIOS") configuration.
After that it'll probably not have the right drivers in the initramfs. Symptoms would be that it gets to grub, then boots the kernel, but fails when mounting the root filesystem. Luckily this is easier to solve - identify which drivers are needed for the target hardware and before copying across, run “dracut --add-drivers ..” You'll have to read the dracut man page closely.
Update is that after changing the hardware to use UEFI it booted all the way (a little surprising?)
It's a great outcome, but not really surprising -- this is how things *should* work. While the platform firmware on the physical machine did not have a UEFI boot option for the RHEL-8.6 OS, RHEL-8.6 does provide the "fallback" boot path, so it works. Basically: provide a special boot loader at the default boot path that is otherwise only used with removable media, namely, \EFI\BOOT\BOOTX64.EFI. This utility (originally called "fallback.efi", from the shim project) then recreates the proper UEFI boot options, from a small CSV table that's also kept on the EFI system partition. For this to work, the platform firmware and the (original) OS installer must co-operate. Debian used not to provide such a fallback -- I'm not sure about their current status.
But the keyboard doesn't work. This is also surprising because I *thought* that both virt and baremetal basically use emulated or real USB keyboard these days.
The keyboard does not work -- where? Once the OS is reached (gdm or console root prompt), or in grub (pre-boot, basically)? The latter, I can explain. UEFI has a phase called "Boot Device Selection" (BDS) where the firmware decides exactly what devices to "connect" -- meaning what devices should be *bound* by UEFI drivers. There is a number of policies here; the gist is that the platform vendor can do whatever they want -- BDS is called "platform policy". Usually they support at least two configs, "full config" and "fast boot". Under "fast boot", the firmware only connects such devices to UEFI drivers that the firmware *knows* are needed for booting, and ignores everything else, including newly connected devices, potentially. Therefore, a USB keyboard could end up "non-driven" by UEFI because it is not needed for booting! The fix is to get into the firmware setup UI by some other way [*], and either disable "fast boot", or -- if the firmware is flexible enough -- explicitly enable the binding of USB devices. [*] From "/etc/grub.d/30_uefi-firmware", the command grub2-mkconfig -o /etc/grub2-efi.cfg should create a grub2 menu entry, usually at the end of the boot menu, that invokes the "fwsetup" grub2 command. The trick is to make this entry the default entry, once the OS has fully booted (I guess via GRUB_DEFAULT in "/etc/default/grub"), and then reboot. When grub2 executes "fwsetup", it modifies a particular non-volatile UEFI global variable ("OsIndications"), and upon seeing that, the firmware at next boot will drop into the setup UI. Thanks Laszlo
On Thu, May 19, 2022 at 12:25:53PM +0200, Laszlo Ersek wrote:
On 05/18/22 15:30, Richard W.M. Jones wrote:
But the keyboard doesn't work. This is also surprising because I *thought* that both virt and baremetal basically use emulated or real USB keyboard these days.
[This bit is wrong - on x86 under virt we emulate a PS/2 keyboard]
The keyboard does not work -- where?
Once the OS is reached (gdm or console root prompt), or in grub (pre-boot, basically)?
It got all the way to gdm but apparently the keyboard didn't work for login etc. The baremetal server is a Dell and Guilherme was accessing this over iDRAC. No idea what kind of "virtual" keyboard iDRAC presents to the hardware. I don't know what happened in the end. Last I heard Guilherme was trying to reach the server over ssh.
The latter, I can explain. UEFI has a phase called "Boot Device Selection" (BDS) where the firmware decides exactly what devices to "connect" -- meaning what devices should be *bound* by UEFI drivers.
There is a number of policies here; the gist is that the platform vendor can do whatever they want -- BDS is called "platform policy".
Usually they support at least two configs, "full config" and "fast boot". Under "fast boot", the firmware only connects such devices to UEFI drivers that the firmware *knows* are needed for booting, and ignores everything else, including newly connected devices, potentially. Therefore, a USB keyboard could end up "non-driven" by UEFI because it is not needed for booting!
Would Linux still recognise the keyboard even in "fast boot" mode?
The fix is to get into the firmware setup UI by some other way [*], and either disable "fast boot", or -- if the firmware is flexible enough -- explicitly enable the binding of USB devices.
[*] From "/etc/grub.d/30_uefi-firmware", the command
grub2-mkconfig -o /etc/grub2-efi.cfg
should create a grub2 menu entry, usually at the end of the boot menu, that invokes the "fwsetup" grub2 command. The trick is to make this entry the default entry, once the OS has fully booted (I guess via GRUB_DEFAULT in "/etc/default/grub"), and then reboot. When grub2 executes "fwsetup", it modifies a particular non-volatile UEFI global variable ("OsIndications"), and upon seeing that, the firmware at next boot will drop into the setup UI.
Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
On 05/18/22 14:56, Richard W.M. Jones wrote:
On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote:
Greetings masters,
I got pointed to you guys as experts on smtg I'm struggling with. I'm trying to move an ovirt vm raw image to a bm machine and though [bm = baremetal] I could do it successfully using dd (got able to see and work with the partitions and the data fine), I couldn't boot the disk.
It may be an issue with drivers (like the virtio drivers), but idk, and I'm wondering if someone has done smtg similar or could help somehow with the process.
So in IRC we established that it's a RHEL 8.6 guest, and that it doesn't get as far as grub. The virtual machine boots with UEFI and the physical machine boots with BIOS which is why grub doesn't work.
Conversion of a machine from UEFI to BIOS is usually quite tricky. Are you sure the baremetal machine doesn't support UEFI booting? Almost anything made in the last 10 years should, although you may have to adjust the firmware ("BIOS") configuration.
I agree that Guilherme should first try to make the UEFI boot path work -- dependent on the partitioning of the VM disk image (GPT?), I figure there might not be a *place* on the physical disk to install BIOS grub2 to! Thanks Laszlo
After that it'll probably not have the right drivers in the initramfs. Symptoms would be that it gets to grub, then boots the kernel, but fails when mounting the root filesystem. Luckily this is easier to solve - identify which drivers are needed for the target hardware and before copying across, run “dracut --add-drivers ..” You'll have to read the dracut man page closely.
Rich.
participants (3)
-
Guilherme De Oliveira Santos -
Laszlo Ersek -
Richard W.M. Jones