vmdk to cqow2 invalid VMDK image descriptor

Greetings, 

CentOS 7.5.1804
Linux 3.10.0-862.11.6.el7.x86_64 
qemu-img version 3.0.50 (v3.0.0-614-g19b599f)

When trying to convert a vmdk flat file to qcow2 format, I get the following error message:
qemu-img: Could not open './sk-R12-flat.vmdk': invalid VMDK image descriptor

The command line used is
root@s11kvm:/home/goinfre> qemu-img convert -f vmdk -O qcow2 ./sk-R12-flat.vmdk ./sk-R12-flat.qcow2


"file sk-R12-flat.vmdk" returns:
sk-R12-flat.vmdk: x86 boot sector;
GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x40, GRUB version 0.97;
partition 1: ID=0x63, active, starthead 1, startsector 63, 16002 sectors; 
partition 2: ID=0x83, starthead 0, startsector 16065, 3084480 sectors; 
partition 3: ID=0x83, starthead 0, startsector 3100545, 3084480 sectors; 
partition 4: ID=0x5, starthead 0, startsector 6185025, 161581770 sectors, code offset 0x48

Found a work around by removing the option "-f vmd"
Still a bug though. 

meant "vmdk" of course. 

Hi,

Judging from the "file" output and the fact that you say the result is correct when removing "-f vmdk", it appears as if the input is in fact not in vmdk format but just a raw image.
I don't know too much about vmdk, but I suppose that there is a descriptor file that goes aloing with that sk-R12-flat.vmdk (e.g. "sk-R12.vmdk").  So I guess sk-R12-flat.vmdk just contains the raw image data which is pointed to by e.g. sk-R12.vmdk, and the latter would be the file that qemu expects.

From my perspective, giving the flat file a .vmdk extension is a misnomer, and qemu's vmdk driver is correct in rejecting it -- because it is just a raw file, so it should be handled by the raw driver.  But maybe it is common enough that the vmdk driver should give a hint on that.

Note that the VMware knowledge base (https://kb.vmware.com/s/article/1002511) specifically says that "VMDK" stands for the descriptor file, and it looks like even VMware would reject flat files without a descriptor file.

Max

I'm closing this ticket since it was likely just a wrong file extension ... if you disagree, feel free to open the ticket again.