Bug 1299250

Summary: qemu-img created VMDK images are unbootable
Product: Red Hat Enterprise Linux 7 Reporter: Robert Scheck <redhat-bugzilla>
Component: qemu-kvmAssignee: Fam Zheng <famz>
Status: CLOSED ERRATA QA Contact: Ping Li <pingl>
Severity: medium Docs Contact: Yehuda Zimmerman <yzimmerm>
Priority: unspecified    
Version: 7.2CC: chayang, famz, huding, inetkach, jherrman, juzhang, knoel, ppostler, rbalakri, virt-maint, xfu, yuhuang, yzimmerm
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: qemu-kvm-1.5.3-111.el7 Doc Type: Release Note
Doc Text:
Data layout of VMDK images with streamOptimized sub-format was incorrect Previously, the data layout of a Virtual Machine Disk (VMDK) image with a streamOptimized sub-format created by the qemu-img tool was incorrect. This prevented the VMDK image from being bootable when imported to ESX servers. In this update, the image is converted to a valid VMDK streamOptimized image. This results in the VMDK image being bootable.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 20:09:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1203710, 1305606, 1313485, 1299116    
Description Flags
/tmp/example.ovf.sh none

Description Robert Scheck 2016-01-17 20:45:38 UTC
Created attachment 1115668 [details]

Description of problem:
Any VMDK image created by qemu-img is unbootable. Note that the import of
the VMDK image via OVA fails already before (due to bug #1299116). Failure
in VMware looks like this:

--- snipp ---
error: unknown filesystem.
Entering rescue mode...
grub rescue> _
--- snapp ---

Version-Release number of selected component (if applicable):
VMware vSphere Client, Version 5.1.0, Build 1064113
VMware ESXi, Version 5.1.0, Build 1065491, German-000

How reproducible:
Everytime, see above and below.

Steps to Reproduce:
1. dd if=/dev/zero of=/tmp/example.img bs=1M count=1200
2. parted /tmp/example.img mktable msdos
3. parted /tmp/example.img mkpart primary ext4 1 -- -0
4. parted /tmp/example.img set 1 boot on
5. kpartx -avs /tmp/example.img
6. mkfs.ext4 /dev/mapper/loop0p1
7. mkdir -p /mnt/example/
8. mount /dev/mapper/loop0p1 /mnt/example/
9. yum -y --releasever=7 --nogpg --installroot=/mnt/example install \
     systemd passwd centos-release kernel grub2
10. mount --bind /dev /mnt/example/dev
11. mount --bind /proc /mnt/example/proc
12. mount --bind /sys /mnt/example/sys
13. echo "GRUB_TIMEOUT=5" > /mnt/example/etc/default/grub
14. echo "GRUB_DISTRIBUTOR=\"\$(sed 's, release .*$,,g' \
      /etc/system-release)\"" >> /mnt/example/etc/default/grub
15. echo "GRUB_DEFAULT=saved" >> /mnt/example/etc/default/grub
16. echo "GRUB_DISABLE_SUBMENU=true" >> /mnt/example/etc/default/grub
17. echo "GRUB_TERMINAL_OUTPUT=\"console\"" >> \
18. echo "GRUB_CMDLINE_LINUX=\" vconsole.keymap=de \
      vconsole.font=latarcyrheb-sun16\"" >> \
19. echo "GRUB_DISABLE_RECOVERY=\"true\"" >> \
20. chroot /mnt/example/ grub2-mkconfig -o /boot/grub2/grub.cfg
21. chroot /mnt/example/ grub2-install /dev/loop0
22. umount /mnt/example/dev
23. umount /mnt/example/proc
24. umount /mnt/example/sys
25. umount /mnt/example/
26. kpartx -dvs /tmp/example.img
27. qemu-img convert /tmp/example.img -O vmdk \
      -o adapter_type=lsilogic,subformat=streamOptimized,compat6 \
28. printf '\x03' | dd conv=notrunc of=/tmp/example-disk1.vmdk \
      bs=1 seek=$((0x4))
29. sh /tmp/example.ovf.sh
30. tar -C /tmp/ -cf /tmp/example.ova example.ovf example-disk1.vmdk
31. Import example.ova into VMware -> fails with error above

Actual results:
qemu-img created VMDK images are unbootable

Expected results:
qemu-img created VMDK images should be bootable. Repeating the steps
above with qemu-img-2.5.0-3.fc24.x86_64 (rebuilt from Fedora Rawhide
for RHEL 7) leads to success.

Additional info:
Virtual size alternatively from: qemu-img info /tmp/example-disk1.vmdk

Comment 2 Ademar Reis 2016-01-19 17:03:55 UTC
Robert, thanks for the bugreport.

As I said in the other BZ (bug 1299116), 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

Comment 3 Robert Scheck 2016-01-19 17:38:51 UTC
Ademar, thanks for the reminder.

Cross-filed case 01569297 on the Red Hat customer portal.

Comment 5 Robert Scheck 2016-02-15 11:01:32 UTC
Does this mean there is something to test? If so, may you share the testing
update with me (either here or via the ticket), please?

Comment 6 Fam Zheng 2016-02-15 13:21:31 UTC
Yes, you can test the scratch build rpms that include the fixes for this bug (and bz 1299116):


Comment 7 Robert Scheck 2016-02-15 13:37:23 UTC
Thanks! Btw, is it intended that there is no SRPM? The %changelog does not
mention anything, so I am wondering if it's really patched (before running
my tests).

Comment 9 Fam Zheng 2016-02-18 08:28:55 UTC
My reply to comment 7 from the other day got lost.

Robert, the SRPM is not preserved but the packages do have the fix.



Comment 10 Robert Scheck 2016-02-21 14:12:36 UTC
I would like to confirm that the updated RPM (qemu-img-1.5.3-108.el7.test)
works fine for me and passed all my tests regarding this issue.

Comment 11 Fam Zheng 2016-02-22 01:39:56 UTC
Great, thanks!

Comment 12 Mike McCune 2016-03-28 22:35:49 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 13 Miroslav Rezanina 2016-05-05 06:38:37 UTC
Fix included in qemu-kvm-1.5.3-111.el7

Comment 15 Ping Li 2016-07-26 15:00:13 UTC
Reproduced the issue with qemu-kvm-1.5.3-110.el7.x86_64. After step 7, guest cannot boot up.

Verified the issue with qemu-kvm-1.5.3-111.el7.x86_64(Step 3 is unnecessary). After step 7, guest can boot up successfully.

Steps to reproduce:
1. Create a guest on ESXi 5.1 via vSphere and copy out the flat vmdk file(such as rhel6.8z_64_lazy-flat.vmdk, rename it as example.img. The format of the file is raw).
2. qemu-img convert example.img -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6 example.vmdk
3. printf '\x03' | dd conv=notrunc of=example.vmdk bs=1 seek=$((0x4))
4. sh example.ovf.sh
5. tar cf example.ova example.ovf example.vmdk
6. Import example.ova into ESXi 5.1.
7. Boot up the guest.

Comment 19 errata-xmlrpc 2016-11-03 20:09:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.