Hi Vijay
Based on your initial post about using virt-v2v I don't know how
intelligent virt-v2v is in knowing and converting the VM machine type.
However the boot issue could be related to Hyper-V defaulting to "Gen 2"
VMs which are all UEFI based. Hence your current VMs
should have a FAT32 partition with an EFI loader. oVirt by default emulates
440FX Chipset and a legacy SeaBIOS.
Only so-called Gen 1 VMs were emulating a legacy BIOS on the Hyper-V side.
You should be able to check VM generation on Hyper-V using this PowerShell
command:
Get-VM | Format-List Name,Generation
If it is a Gen 2 VM, starting with oVirt 4.3 you could try booting a
converted disk on a VM with Q35 and OVMF (UEFI).
Keep in mind that 4.3 still has some rough edges in that area. For example
all settings written to the UEFI NVRAM get lost when turning off
and on the VM in oVirt. This affects the bootloader entries in OVMF that an
OS installer eventually created during setup.
Thus the OVMF only ever looks for an EFI loader bootloader in the path
boot/efi/bootx64.efi in that FAT32 partition.
However if that path is not present, OVMF should open the "BIOS settings"
and you should be able to "boot from file" and then
select the .efi file if the given operating system and make an attempt at
booting the guest OS.
The current workaround that seems to work now is to copy the OS's .efi
loader to the default location OVMF is looking for a bootloader
as described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1727987
Regards,
Mathieu