Hide Forgot
Created attachment 1229400 [details] Output from Azure VHD Utils inspecting the footer of a valid dynamic VHD image. Description of problem: Converting a custom raw image to dynamic VHD results in a VHD image with an invalid footer. Using Microsoft's Azure VHD Utils (https://github.com/Microsoft/azure-vhd-utils) to inspect the dynamic VHD image results in an error: Parse footer field 'Cookie' failed: Invalid footer cookie data [0 0 0 0 0 0 0 0] Fedora 25's package of qemu-img, version 2.7.0, can convert raw images to dynamic VHD images successfully, resulting in a bootable VHD image for Azure. Version-Release number of selected component (if applicable): qemu-img-1.5.3-126.el7.x86_64.rpm How reproducible: Always Steps to Reproduce: 1. Convert a raw disk image to dynamic VHD $ qemu-img convert -f raw guest.img -o subformat=dynamic -O vpc guest.vhd 2. Use Azure VHD Utils to inspect the image $ /opt/go/bin/azure-vhd-utils inspect header --path guest.vhd Parse footer field 'Cookie' failed: Invalid footer cookie data [0 0 0 0 0 0 0 0] Actual results: qemu-img creates a dynamic VHD with an invalid footer. Azure VHD Utils cannot validate the VHD image. Expected results: qemu-img creates a valid dynamic VHD. Azure VHD Utils successfully inspects the image, and prints a footer. Additional info: The Red Hat documentation specifies that users should convert to fixed VHD formats, as Azure only supports fixed VHD images. However, some upload utilities for Azure support converting images from dynamic to fixed on the fly. Smaller, dynamic images are much easier to manage than the fullsize images, and hash calculation before uploading is much faster for a dynamic image. See the attachment for output from Azure VHD Utils when inspecting a dynamic VHD image created by qemu-img version 2.7.0, as found in Fedora 25.
Further analysis of both images with hexdump shows that Red Hat's qemu-img seems to create the footer at the correct location, but appends zeroes to the image until it matches the virtual size. Dumping the last 512 bytes from the valid dynamic VHD on Fedora shows the following: $ hexdump -C -s 1424367104 valid.vhd 54e61e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| 54e61e10 00 00 00 00 00 00 02 00 1f db ec ec 71 65 6d 75 |............qemu| 54e61e20 00 05 00 03 57 69 32 6b 00 00 00 06 40 02 60 00 |....Wi2k....@.`.| 54e61e30 00 00 00 06 40 02 60 00 cb 2d 10 3f 00 00 00 03 |....@.`..-.?....| 54e61e40 ff ff ec 3e d2 9b 40 ef f3 cb 43 03 92 6d 40 0c |...>..@...C..m@.| 54e61e50 86 21 d6 6e 00 00 00 00 00 00 00 00 00 00 00 00 |.!.n............| 54e61e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 54e62000 The footer is present in the exact same location when converted by Red Hat's qemu-img: # hexdump invalid.vhd -C -s 1424367104 -n 512 54e61e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| 54e61e10 00 00 00 00 00 00 02 00 1f db dd be 71 65 6d 75 |............qemu| 54e61e20 00 05 00 03 57 69 32 6b 00 00 00 06 40 12 20 00 |....Wi2k....@. .| 54e61e30 00 00 00 06 40 12 20 00 cb 2f 10 3f 00 00 00 03 |....@. ../.?....| 54e61e40 ff ff ed 1d 1f 44 0f ef cf a0 40 46 91 07 c0 fb |.....D....@F....| 54e61e50 0d e8 f1 03 00 00 00 00 00 00 00 00 00 00 00 00 |................| 54e61e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 54e62000 Dumping the remaining data shows that it only contains zeroes until the end of the file: # hexdump invalid.vhd -C -s 1424367104 54e61e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| 54e61e10 00 00 00 00 00 00 02 00 1f db dd be 71 65 6d 75 |............qemu| 54e61e20 00 05 00 03 57 69 32 6b 00 00 00 06 40 12 20 00 |....Wi2k....@. .| 54e61e30 00 00 00 06 40 12 20 00 cb 2f 10 3f 00 00 00 03 |....@. ../.?....| 54e61e40 ff ff ed 1d 1f 44 0f ef cf a0 40 46 91 07 c0 fb |.....D....@F....| 54e61e50 0d e8 f1 03 00 00 00 00 00 00 00 00 00 00 00 00 |................| 54e61e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 640100000
Robin, thanks for taking the time to enter a bug report with us. We use reports like yours to keep improving the quality of our products and releases. That said, we're not able to guarantee the timeliness or suitability of a resolution for issues entered here because this is not a mechanism for requesting support. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization that will result in a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto
(In reply to Ademar Reis from comment #3) > Robin, thanks for taking the time to enter a bug report with us. We use > reports like yours to keep improving the quality of our products and > releases. That said, we're not able to guarantee the timeliness or > suitability of a resolution for issues entered here because this is not a > mechanism for requesting support. > > If this issue is critical or in any way time sensitive, please raise a > ticket through your regular Red Hat support channels to make certain it > receives the proper attention and prioritization that will result in a > timely resolution. > > For information on how to contact the Red Hat production support team, > please visit: https://www.redhat.com/support/process/production/#howto As a follow-up to this case: we're not considering this a priority at the moment and I'm closing this BZ. This might be incorporated in a future version of RHEL or other Red Hat products if/when patches get merged upstream. As mentioned before, please contact Red Hat support to make certain this receives the proper attention and prioritization.