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
Regards,
Mathieu