Duplicate - Same issue related to header/footer - When does the code fix
show up in the git release train ?
bug 907063 .
Read the VMDK 5.X release doc on format for VMDK. The files im using are
created from Vsphere 5.X and are using a VMDK verion of 3.
Virtual Disk Format 5.0 - VMware
www.vmware.com/support/.../vmdk_50_technote.pdf?src=vm...
File Format: PDF/Adobe Acrobat - Quick View
Dec 20, 2011 – The document describes the virtual machine disk (VMDK) format
and ... VMware designed the VMDK (virtual machine disk) format to mimic the ...
Fields look consistent with description in the VMDK 5.X doc and used that
struct as referene(hacked patch attached for reference
)
First pass at Header:
gdb) p/x header
$1 = {version = 0x3, flags = 0x30001, capacity = 0x400000, granularity = 0x80,
desc_offset = 0x1,
desc_size = 0x1, num_gtes_per_gte = 0x200, rgd_offset = 0x0, gd_offset =
0xffffffffffffffff,
grain_offset = 0x80, uncleanshutdown = 0x0, singlendlinechar = 0xa,
nonendlinechar = 0x20,
doublendlinechar1 = 0xd, doublendlinechar2 = 0xa, compressAlgorithm = 0x1,
pad = {
0x0 <repeats 433 times>}}
Now the footer:
(gdb) p/x header
$2 = {version = 0x3, flags = 0x30001, capacity = 0x400000, granularity = 0x80,
desc_offset = 0x1,
desc_size = 0x1, num_gtes_per_gte = 0x200, rgd_offset = 0x0, gd_offset =
0x68304,
grain_offset = 0x80, uncleanshutdown = 0x0, singlendlinechar = 0xa,
nonendlinechar = 0x20,
doublendlinechar1 = 0xd, doublendlinechar2 = 0xa, compressAlgorithm = 0x1,
pad = {
0x0 <repeats 433 times>}}
** Attachment added: "vmdk4-qemu-img"
https://bugs.launchpad.net/qemu/+bug/1075252/+attachment/3426186/+files/vmdk4-qemu-img
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1075252
Title:
qemu-img cannot read VMDK4 file
Status in QEMU:
New
Bug description:
Unable to read any vmdk4 type files. Goal was to convert to a qcow2,
this worked after emitting code.
OS is Centos linux 2.6.32. I pulled the latest git tree down for qemu
to see if this was resolved, it is not.
Starting program: /home/rhubbard/QEMU/qemu/qemu-img info -f vmdk
/root/Juniper/beta1candidate-07122012-disk1.vmdk
There seems a mismatch with the l1_backup_tble_offset. this is now a uint64
type. The value is actually "-512" because of this and this causes the code
check at line 418 in vmdk.c to erroneously think there is a backup table. This
causes vmdk open to fail.
and message
qemu failed to open ....
from debug;
gdb) x/4x &(s->l1_backup_table_offset)
0xa61cd0: 0xfffffe00 0xffffffff 0x00a62770 0x00000000
(gdb) p *s
$1 = {hd = 0x0, l1_table_offset = 0, l1_backup_table_offset = -512, l1_table
= 0xa62770,
l1_backup_table = 0x0, l1_size = 64, l1_entry_sectors = 65536, l2_size =
512, l2_cache = 0x0,
l2_cache_offsets = {0 <repeats 16 times>}, l2_cache_counts = {0 <repeats 16
times>},
cluster_sectors = 128, parent_cid = 4294967295}
typedef struct BDRVVmdkState {
BlockDriverState *hd;
int64_t l1_table_offset; <====
??? - what should this be , don't know what the actual layout on the vmdk spec
says , is this a 64bit / 8 byte field ?
int64_t l1_backup_table_offset;
uint32_t *l1_table;
uint32_t *l1_backup_table;
unsigned int l1_size;
uint32_t l1_entry_sectors;
unsigned int l2_size;
from vmdk.c
/*!!! if (s->l1_backup_table_offset) {
s->l1_backup_table = qemu_malloc(l1_size);
if (bdrv_pread(bs->file, s->l1_backup_table_offset,
s->l1_backup_table, l1_size) != l1_size)
goto fail;
Breaks here..
Don't know the correct fix , thanks for help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1075252/+subscriptions
