1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
permissions: 0.818
other: 0.769
semantic: 0.687
graphic: 0.623
debug: 0.567
device: 0.565
network: 0.489
PID: 0.470
performance: 0.459
vnc: 0.438
boot: 0.402
KVM: 0.401
socket: 0.378
files: 0.338
Error reading VMDK4 with footer instead of header
VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have.
bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :(
I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it.
On Tue, Dec 20, 2011 at 8:53 PM, bbgordonn <email address hidden> wrote:
> Public bug reported:
>
> VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
> "). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
>
> I have regression-tested this with various OVAs exported from
> VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were
> unable to import any compressed VMDKs with a footer. It now works on all
> the ones I have.
>
> bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset
> and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec
> from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_
> *before* rgd_offset. I was only able to get VMDK conversion to work by
> switching the order back to that specified by VMWare and previously used
> by QEMU. I don't know what VMDK this commit is referring to, so I can't
> test to see if I've broken it. :(
>
> I will submit this patch to the mailing list if I get a chance, but I'm
> also uploading it here so I don't lose it.
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/907063
Thanks for reporting this. I have CCed Fam who worked on VMDK this summer.
Please submit patches to the mailing list according to the guidelines here:
http://wiki.qemu.org/Contribute/SubmitAPatch
Stefan
Looks like something similar has been commited here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65bd155c7356d448ffee7
So is this problem fixed nowadays?
[Expired for QEMU because there has been no activity for 60 days.]
|