Bug 511129
Summary: | no error given for vmdk files which are NOT version 3 or 4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gene Czarcinski <gczarcinski> |
Component: | qemu | Assignee: | Glauber Costa <gcosta> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | 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 15:22:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gene Czarcinski
2009-07-13 20:15:45 UTC
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 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 > 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 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! 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? |