Bug 1299250 - qemu-img created VMDK images are unbootable
qemu-img created VMDK images are unbootable
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.2
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Fam Zheng
Ping Li
Yehuda Zimmerman
:
Depends On:
Blocks: 1203710 1305606 1313485 1299116
  Show dependency treegraph
 
Reported: 2016-01-17 15:45 EST by Robert Scheck
Modified: 2016-11-03 16:09 EDT (History)
13 users (show)

See Also:
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 16:09:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/tmp/example.ovf.sh (7.54 KB, text/plain)
2016-01-17 15:45 EST, Robert Scheck
no flags Details

  None (edit)
Description Robert Scheck 2016-01-17 15:45:38 EST
Created attachment 1115668 [details]
/tmp/example.ovf.sh

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):
qemu-img-1.5.3-105.el7_2.1.x86_64
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\"" >> \
      /mnt/example/etc/default/grub
18. echo "GRUB_CMDLINE_LINUX=\" vconsole.keymap=de \
      vconsole.font=latarcyrheb-sun16\"" >> \
      /mnt/example/etc/default/grub
19. echo "GRUB_DISABLE_RECOVERY=\"true\"" >> \
      /mnt/example/etc/default/grub
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 \
      /tmp/example-disk1.vmdk
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 12:03:55 EST
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 12:38:51 EST
Ademar, thanks for the reminder.

Cross-filed case 01569297 on the Red Hat customer portal.
Comment 5 Robert Scheck 2016-02-15 06:01:32 EST
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 08:21:31 EST
Yes, you can test the scratch build rpms that include the fixes for this bug (and bz 1299116):

http://people.redhat.com/fzheng/bz1299250/
Comment 7 Robert Scheck 2016-02-15 08:37:23 EST
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 03:28:55 EST
My reply to comment 7 from the other day got lost.

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

Thanks,

Fam
Comment 10 Robert Scheck 2016-02-21 09:12:36 EST
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-21 20:39:56 EST
Great, thanks!
Comment 12 Mike McCune 2016-03-28 18:35:49 EDT
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 02:38:37 EDT
Fix included in qemu-kvm-1.5.3-111.el7
Comment 15 Ping Li 2016-07-26 11:00:13 EDT
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 16:09:53 EDT
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.

https://rhn.redhat.com/errata/RHSA-2016-2585.html

Note You need to log in before you can comment on or make changes to this bug.