Description of problem: oVirt sets only 1 disk as bootable (and thus only it has the 'boot order' argument), and thus during the boot process only that device is visible. When a VM (tested with EL7 & EL8) is using a raid0 spread among multiple disks, grub cannot assemble the raid0 (the visible raid members are not enough for assembly) and ends to grub rescue. Version-Release number of selected component (if applicable): ipxe-roms-qemu-20181214-8.git133f4c47.el8.noarch libvirt-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-client-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-config-network-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-config-nwfilter-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-interface-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-network-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-nodedev-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-nwfilter-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-qemu-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-secret-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-core-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-disk-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-gluster-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-iscsi-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-iscsi-direct-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-logical-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-mpath-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-rbd-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-driver-storage-scsi-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-daemon-kvm-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-libs-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 libvirt-lock-sanlock-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 python3-libvirt-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64 qemu-img-6.0.0-33.el8s.x86_64 qemu-kvm-6.0.0-33.el8s.x86_64 qemu-kvm-block-curl-6.0.0-33.el8s.x86_64 qemu-kvm-block-gluster-6.0.0-33.el8s.x86_64 qemu-kvm-block-iscsi-6.0.0-33.el8s.x86_64 qemu-kvm-block-rbd-6.0.0-33.el8s.x86_64 qemu-kvm-block-ssh-6.0.0-33.el8s.x86_64 qemu-kvm-common-6.0.0-33.el8s.x86_64 qemu-kvm-core-6.0.0-33.el8s.x86_64 qemu-kvm-docs-6.0.0-33.el8s.x86_64 qemu-kvm-hw-usbredir-6.0.0-33.el8s.x86_64 qemu-kvm-ui-opengl-6.0.0-33.el8s.x86_64 qemu-kvm-ui-spice-6.0.0-33.el8s.x86_64 vdsm-4.40.90.4-1.el8.x86_64 vdsm-api-4.40.90.4-1.el8.noarch vdsm-client-4.40.90.4-1.el8.noarch vdsm-common-4.40.90.4-1.el8.noarch vdsm-gluster-4.40.90.4-1.el8.x86_64 vdsm-http-4.40.90.4-1.el8.noarch vdsm-jsonrpc-4.40.90.4-1.el8.noarch vdsm-network-4.40.90.4-1.el8.x86_64 vdsm-python-4.40.90.4-1.el8.noarch vdsm-yajsonrpc-4.40.90.4-1.el8.noarch How reproducible: Always Steps to Reproduce: 1.Migrate from oVirt 4.3.10 to 4.4.9 2.Set the cluster level to 4.6 3.Power up a VM that previously was working fine Actual results: VM is in grub rescue. When typing "ls" only the partitions for "hd0" are visible (md device is visible as one of the members is there, but cannot boot) Expected results: As before , the VM should be able to boot. One option is to allow multiple disks to be flagged as bootable or to fix the regression Additional info: In order to recover such VM, you can do the following: 1. Start the VM and while it's in grub's rescue shell dump the configuration: virsh dumpxml VM > VM.xml 2. Shutdown the Vm 3. Edit the VM.xml , so every disks in the raid have a "boot order" attribute 4. Define the modified version of the VM virsh define VM.xml 5. Start the VM virsh start VM 6. After some time, the engine notices that the VM is running with "run-once" configuration and will mark it as UP in the UI. VM example layout: [root@nextcloud ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 5G 0 disk ├─sda1 8:1 0 500M 0 part │ └─md127 9:127 0 2G 0 raid0 /boot └─sda2 8:2 0 4,5G 0 part └─nextcloud--system-root 253:0 0 10G 0 lvm / sdb 8:16 0 5G 0 disk ├─sdb1 8:17 0 500M 0 part │ └─md127 9:127 0 2G 0 raid0 /boot └─sdb2 8:18 0 4,5G 0 part └─nextcloud--system-root 253:0 0 10G 0 lvm / sdc 8:32 0 5G 0 disk ├─sdc1 8:33 0 500M 0 part │ └─md127 9:127 0 2G 0 raid0 /boot └─sdc2 8:34 0 4,5G 0 part └─nextcloud--system-root 253:0 0 10G 0 lvm / sdd 8:48 0 5G 0 disk ├─sdd1 8:49 0 500M 0 part │ └─md127 9:127 0 2G 0 raid0 /boot └─sdd2 8:50 0 4,5G 0 part └─nextcloud--system-root 253:0 0 10G 0 lvm / sde 8:64 0 1G 0 disk └─nextcloud--db-db 253:2 0 4G 0 lvm /var/lib/mysql sdf 8:80 0 1G 0 disk └─nextcloud--db-db 253:2 0 4G 0 lvm /var/lib/mysql sdg 8:96 0 1G 0 disk └─nextcloud--db-db 253:2 0 4G 0 lvm /var/lib/mysql sdh 8:112 0 1G 0 disk └─nextcloud--db-db 253:2 0 4G 0 lvm /var/lib/mysql sdi 8:128 0 300G 0 disk └─data-slow 253:1 0 600G 0 lvm /var/www/html/nextcloud/data sdj 8:144 0 300G 0 disk └─data-slow 253:1 0 600G 0 lvm /var/www/html/nextcloud/data sr0
I forgot to mention that newly built VMs are affected while in 4.2/4.3 booting from Raid0 was absolutely possible even if only the first disk was marked as bootable.
Tomas, can you please take a look? it looks similar to bz 1924972
Yes, in my opinion it is a duplicate of bug 1924972. I have already pointed that out on the ML couple days back, I didn't know there's already a bug for that.
To confirm could you please provide also the version of seabios on the host and whether this concerns VMs with BIOS or UEFI?
All my VMs are BIOS. Seabios version on the hypervisour is: seabios-bin-1.14.0-1.module_el8.6.0+983+a7505f3f.noarch
*** This bug has been marked as a duplicate of bug 1924972 ***