Bug 511129

Summary: no error given for vmdk files which are NOT version 3 or 4
Product: [Fedora] Fedora Reporter: Gene Czarcinski <gczarcinski>
Component: qemuAssignee: Glauber Costa <gcosta>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: dwmw2, gcosta, itamar, jaswinder, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-14 11:22:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Gene Czarcinski 2009-07-13 16:15:45 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.)

How reproducible:
everytime
Comment 1 Mark McLoughlin 2009-08-07 09:01:44 EDT
As I suggested on fedora-virt:

  http://www.redhat.com/archives/fedora-virt/2009-July/msg00159.html

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
Comment 2 Gene Czarcinski 2009-08-11 15:05:23 EDT
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.
Comment 3 Mark McLoughlin 2009-08-14 06:28:13 EDT
(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
> file.

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
Comment 4 Gene Czarcinski 2009-08-14 10:56:41 EDT
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?
Comment 5 Mark McLoughlin 2009-08-14 11:22:24 EDT
(In reply to comment #4)
> At this point, I would prefer to close this!

Thanks, closing

> Any ideas on how to make that happen?  

It sounds to me like this could be done with a libguestfs VMWare->KVM migration tool?