qemu-img is actually what HyperCore OS uses internally when it is doing both import and export of VM's to/from HC3. As a result, if you use the "foreign VM import" process referenced above, it leverages the fact that if you simply rename a vmdk for example to a qcow2 file extension (that HC3 expects) and then import it, qemu-img will actually detect that the disk contained in file is really a VMDK and do that conversion automatically for you saving a step!
One other benefit of letting HC3 do the conversion is that it will convert to the right qcow2 format for that HC3 version automatically. if you are doing the pre-conversion using qemu-img on windows (or linux for that matter), you may want to run the qemu-img info on an empty HC3 exported qcow to see what flags it has and try to match them. depending on the version of HC3 and version of qemu for windows you are using I have seen cases mostly with older versions of HC3 where you need to specify the compat version to match something like this:
qemu-img convert -p -O qcow2 -o preallocation=metadata,compat=0.10 source-image.qcow2 output-image.qcow2(this was an older version of HC3)
On a very new version of HC3 as of this post it looks like compat: 1.1. I got tired messing with stuff like that and the extra step so now I always start with renaming the virtual disk files to .qcow2 extension and try letting HC3 figure it out first at least which generally works. (VHDX may be the exception ... and of course you have to get into the "right" vmdk format in some cases as there are lots of different vmdk formats)
Another tip / FAQ - if you ever have a .OVA file, generally a virtual appliance, that is just a tar archive that you can expand and inside there will be a virtual disk file, usually .vmdk but sometimes .img format that you can convert/import into HC3 using the above processes.
Of course ALL of this is just getting HC3 to see the virtual disk. The OS on that virtual disk has to have the right drivers_ active_ to be able to boot on HC3 which either means that it has virtio drivers pre-installed and set to boot (if "performance" drivers are selected when creating the VM) or IDE drivers (if "compatible" drivers are selected ... and for windows mergeide.reg was run before migration.) Linux is generally just automatic but Windows will result in a 7B BSOD if a driver for the boot disk isn't active on the imported virtual disk.
