Hi,
this seems similar to the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1924972
that was triggered by a change in seabios. Sadly the final comments on
the bug are marked private. At the moment it seams the change in seabios
will be reverted in EL8 (on hypervisor) but it is not clear in which
version will the fix land.
I think somebody once told me that it should be possible to specify
multiple boot disks somehow -- I guess through API? Could you give that
a test? But don't take my word for it. At worst I think you could come
up with a hook that fixes domain XML by adding the bootindex to all
disks.
Hope this helps,
Tomas
On Fri, Jan 07, 2022 at 01:44:08PM +0000, Strahil Nikolov via Users wrote:
Hi Vojta
My LVM version on the hypervisor is:
udisks2-lvm2-2.9.0-7.el8.x86_64
llvm-compat-libs-12.0.1-4.module_el8.6.0+1041+0c503ac4.x86_64
lvm2-libs-2.03.14-2.el8.x86_64
lvm2-2.03.14-2.el8.x86_64
libblockdev-lvm-2.24-8.el8.x86_64
LVM on VM:
[root@nextcloud ~]# rpm -qa | grep lvm
lvm2-libs-2.03.12-10.el8.x86_64
lvm2-2.03.12-10.el8.x86_64
VM disk layout is:
[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 have managed to start my VM as follows:
1. Start the VM
2. Dump the VM xml
3. Destroy
4. Add "<boot order="X" /> to every disk entry in the dump file
5. virsh define VM.xml
6. virsh start VM
Sadly I can't set more than 1 disk as bootable in oVirt.
Best Regards,
Strahil Nikolov В петък, 7 януари 2022 г., 13:38:59 Гринуич+2, Vojtech Juranek
<vjuranek(a)redhat.com> написа:
Hi,
> Hi All,
> I recently migrated from 4.3.10 to 4.4.9 and it seems that booting from
> software raid0 (I have multiple gluster volumes) is not possible with
> Cluster compatibility 4.6 . I've tested creating a fresh VM and it also
> suffers the problem. Changing various options (virtio-scsi to virtio,
> chipset, VM type) did not help . Booting from rescue media shows that the
> data is still there, but grub always drops to rescue. Any hints are
> welcome.
> Host: CentOS Stream 8 with qemu-6.0.0oVirt 4.4.9 (latest)VM OS:
> RHEL7.9/RHEL8.5 Best Regards,Strahil Nikolov
What is the lvm version? There was recently issue [1] with specific lvm version
(lvm2-2.03.14-1.el8.x86_64) which could cause boot failures.
Vojta
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=2026370
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R2NI7T7QUD7...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NVJQXU2VKAB...
--
Tomáš Golembiovský <tgolembi(a)redhat.com>