Red Hat Bugzilla – Bug 511129
no error given for vmdk files which are NOT version 3 or 4
Last modified: 2009-08-14 11:22:24 EDT
Description of problem:
The documentation (e.g., the man page for qemu-img) says that only version 3 and 4 vmdk files are supported. However, no error is indicated if a version other than 3 or 4 (e.g., 7) is used.
I am basing the version on the value of "HWversion" shown by using the strings command against the vmdk file.
The only "error" indication is that the system will no boot up with really strange errors.
Version-Release number of selected component (if applicable):
F11 plus preview (libvirt 0.6.5, etc.)
As I suggested on fedora-virt:
Please run 'hexdump -C -n 4' on your vmdk file
The values for versions 3 and 4 are:
#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
#define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
This will tell us for sure whether you have a version 3 or 4 file
version 4 by your definition.
I was basing (and confused by) some of the other text in header of the vmdk file.
I realize that Fedora 11 is "leading edge" and documentation is often out-of-date or non-existent. However, This definition of vmdk versions should be captured somewhere in qemu documentation. Until I read the message on fedora-vit, I had no idea this was how versions were defined.
(In reply to comment #2)
> version 4 by your definition.
> I was basing (and confused by) some of the other text in header of the vmdk
Does that mean you have a version 4 image which does not boot? If so, let's concentrate on debugging that
Anything in /var/log/libvirt/qemu? What is the actual boot failure?
> I realize that Fedora 11 is "leading edge" and documentation is often
> out-of-date or non-existent. However, This definition of vmdk versions should
> be captured somewhere in qemu documentation. Until I read the message on
> fedora-vit, I had no idea this was how versions were defined.
We ship the latest documentation from upstream.
Probably the best way of identifying if an vmdk is support is to use "qemu-img info foo.vmdk" - it will not print "file format: vmdk" unless its a supported version
At this point, I would prefer to close this! Part of my confusion was that I did not understand how version 3/4 was really defined ... my vmdk files were version 3/4 (one 3 and the rest 4).
All of my problems involved migrating older VMware guest systems with vmdk files. Two of the systems were Fedora and two were Win2k. In all cases, the VMware disks were SCSI disks whereas under qemu-kvm I wanted to use IDE disks.
I finally found a "process" where was successful and this should probably be documented somewhere (besides my messages on the fedora-virt mailing list and the old et-mgmt-tools mailing list). The problem in all cases was that the guest system was trying to use a different device type/drive and the solution is to "update" the device drivers.
For Fedora (Linux) systems, the solution was to simply rerun mkinitrd while under the new hardware configuration by booting up in "rescue mode". This worked fine for one of the Fedora systems but, strangely, not the other. Rather than trying to find this problem, I simply installed an updated kernel (the old guest was out-of-date) and that worked fine.
For the Win2k systems, I had to do something similar -- After defining the new Win2k guest under qemu-kvm and using the vmdk file for the system disk, I booted the Win2k installation disk and used repair mode to reinstall all of the device drivers. I could then boot the guest where I immediately installed the service pack to bring the system up-to-date. Since running repair mode was under the new hardware, it installed to right drivers.
I would close this right now but I think this "process" should be documented so that others can use what I learned. Any ideas on how to make that happen?
(In reply to comment #4)
> At this point, I would prefer to close this!
> Any ideas on how to make that happen?
It sounds to me like this could be done with a libguestfs VMWare->KVM migration tool?