diff options
Diffstat (limited to 'results/classifier/118/permissions/907063')
| -rw-r--r-- | results/classifier/118/permissions/907063 | 89 |
1 files changed, 89 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/907063 b/results/classifier/118/permissions/907063 new file mode 100644 index 000000000..35233a8c2 --- /dev/null +++ b/results/classifier/118/permissions/907063 @@ -0,0 +1,89 @@ +permissions: 0.818 +peripherals: 0.730 +semantic: 0.687 +user-level: 0.666 +graphic: 0.623 +assembly: 0.608 +hypervisor: 0.607 +arm: 0.568 +debug: 0.567 +device: 0.565 +register: 0.548 +risc-v: 0.527 +virtual: 0.520 +ppc: 0.500 +VMM: 0.492 +mistranslation: 0.490 +network: 0.489 +PID: 0.470 +performance: 0.459 +vnc: 0.438 +architecture: 0.416 +boot: 0.402 +x86: 0.401 +KVM: 0.401 +kernel: 0.397 +i386: 0.379 +socket: 0.378 +TCG: 0.340 +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.] + |