<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 4:35 PM, Michal Necasek <span dir="ltr"><<a href="mailto:michal.necasek@oracle.com" target="_blank">michal.necasek@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y7" class="a3s" style="overflow:hidden">  According to my reading of it, qemu-img produced an rater suspect<br>
image. You have a supposedly 64K grain but after decompression, there is<br>
only 49K of data. That's obviously a problem because what do you do with<br>
the missing 15K? You could make something up, but what? Zeros? All bits<br>
set? Random noise? There's no good answer.<br></div></blockquote><div><br></div><div>Well, do you need to make something up?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y7" class="a3s" style="overflow:hidden">
<br>
  If I understood it correctly, in your case the inconsistent grain<br>
occurs at the end of the disk. Does that mean that the size of the disk<br>
in grains is larger than the size in sectors?<br></div></blockquote><div><br></div><div>I think so. I'll verify, but VMware showed some pretty funky numbers for capacity.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y7" class="a3s" style="overflow:hidden">
  At the end of a disk it would be possible to guess "what the user<br>
wanted" but if such a grain occurred in the middle, how do you deal with it?<br></div></blockquote><div><br></div><div>I'm not convinced that you need to. Isn't the image integrity is on the user, and if it is why does VBox care about doing arbitrary checks about data integrity? For OVA we have manifest files to verify the integrity for example.</div><div>Would simply decompressing all the grains and appending them to each other be acceptable?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y7" class="a3s" style="overflow:hidden">
  It might be interesting to check what VMware actually did with it --<br>
what happened with the missing 15K of data? Is it actually in the<br>
imported disk or not?<br></div></blockquote><div><br></div><div>I'll try to get some data on this if it would help getting a decision. Should be simple enough.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y7" class="a3s" style="overflow:hidden">
  To be fair you probably asked qemu-img to do an impossible task. The<br>
grain size must be a power of two and greater than 4K, but your disk<br>
image apparently has a size that's not even a multiple of 2K. The VMDK<br>
spec also says that the capacity of the disk (extent) should be a<br>
multiple of the grain size. So you created a disk image that cannot be<br>
very well be represented as a VMDK.</div></blockquote><div><br></div><div>If this is true qemu-img should be made to complain, not create a "broken" VMDK. The fact that VMware products seem to be able to parse them would possibly imply a grandfather rule. I'm open for rising the question with qemu, but if VBox can be made to handle these images I think that makes more sense. "Be strict when generating output, be liberal when accepting input" -- Sombody somewhere.</div><div><br></div><div>Thanks,</div><div>Chris</div></div><br></div></div>