Converter does not reconfigure Linux machines in case of powered off conversions (by design). Since Hyper-V has a different virtual hardware, it is expected that the destination is unable to boot.
Redo the conversion as P2V (the easier way) or do a manual reconfiguration of the converted VM. E.g. powered on from a live CD, install GRUB (recreating the grub.cfg might be needed) run dracut, check fstab and network configuration files.
I've also used P2V method, but for some reason RHEL7 UEFI based disk are not correctly recognized by VmWare converter, it creates 1 mini disk with UEFI Boot, and another disk that contains the rest of the data (LVM), what it does is getting each disk partition and it converts as a separate disks.
This is not incorrectly recognised, this is by design too. Converter places each LVM volume group on a separate virtual disk.
I suggest you leave it that way. If, for some compelling reason, your organisation need to preserve disk layout, then you'll have to go the manual reconfig way.
Thx For the explanations, I understand that this is the normal behaviour. But there no is any tool that facilitates migrations from other virtualization platforms?
I've found 'qemu', and I'm also tried to use it , but I'm having similar problem that I'll have when I use converter with an offline Hyper-v computer. I guess that I should reconfig virtual machine after conversion as you are suggesting.
Curiosly I'm able to boot without problems If I use as IDE disk.
There is any V2V converter that could preserve disk layout ?
Do you know any blog or reference that explains how to migrate to VmWare without loosing the disk layout? Using qemu or Converter, or... any other tool?
I'll apreciate if you may suggest any method or tool to perform V2V to VmWare
You are welcome.
I am not much knowledgeable about the competition's products. Those I have heard of are Xen convert, Microsoft's converter, Starwind's and Platespin's. MS and Xen, like VMware, aim at importing workload to their hypervisors, so I suppose they won't be of much use in your case. Starwind converter happens to use our dlls, there were even some doubts about how legal this is (it appears to be). True, the modules they reuse are not those that perform Linux reconfig, though I wouldn't expect it to do a great job. I am not sure it does Linux P2V at all, but you may still give it a try. AFAIK Platespin have a good product which is paid, however. I still don't know how it will work in that case.
On the other hand I am curious why do you want to preserve the disk layout? There have been other customers who wanted that, too. OTOH when we designed LVM support for Linux P2V, we thought that that was not an important feature. It would be good to know what reasons there are for disk layout preservation.
P.S. The fact that the machine boots with an IDE disk means that the SCSI controller under Hyper-V is different that the one under ESXi, perhaps not supported by VMware at all. However if it happens to be supported, you may just change it by editing the converted VM and see what happens.
On the other hand I am curious why do you want to preserve the disk layout?
I' will satisfy your curiosity... Is so simply, customer wants to have same layout in all their platform, when you have a large environment it's easy to maintain for support teams, you may work with same procedures/scripting, independently which was the virtualization platform that you are using.
I will try to find how to reconfig virtual machine after conversion.