-
Bug
-
Resolution: Unresolved
-
Undefined
-
rhel-10.1
-
None
-
virt-v2v-2.8.1-10.el10_1
-
No
-
Low
-
1
-
rhel-virt-tools
-
31
-
None
-
False
-
False
-
-
None
-
Bugs with Fixed in Build
-
Approved Exception
-
Unspecified
-
Unspecified
-
Unspecified
-
None
A while back seabios changed how it works so it no longer initializes all disks at boot. This caused problems for virt-v2v especially for guests where grub is not located on the first disk.
It might be fixed by setting the boot order of disks, if we knew what to set that to. Copying the boot order over from VMware is basically impossible as it is not available except in a binary blob on the VMware side.
rhn-engineering-ghoffman suggests this approach instead:
The boot disk (i.e. the device where grub is installed on) should get "<boot order='1'>".
The other disks can get any number higher than 1, the actual order does not matter.
Each disk needs a unique number though, otherwise libvirt will complain that there are duplicates.
This work was done already in RHEL-108991.
However we need to tie this to Kubevirt -o kubevirt mode by setting the boot order there. I didn't investigate yet if Kubevirt supports this.
- clones
-
-
- Release Pending
-
- depends on
-
-
- Release Pending
-
- is cloned by
-
-
- Release Pending
-
- is depended on by
-
MTV-3232 Consume the boot order form virt-v2v kubevirt output
-
- New
-
-
-
- Release Pending
-
- is related to
-
-
- New
-
- links to
-
RHBA-2025:149949
virt-v2v bug fix and enhancement update
