Bug 2041083

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