VMware: can't boot from sparse image copied to volume

[Ryan Hsu]

Using VC Driver, we are unable to boot from a sparse image copied to a volume. Scenario is as follows:

1. Create an image using the cirros vmdk image (linked below) with vmware_disktype="sparse"
2. Copy the image to a volume
3. Boot from the volume

Expected: Able to boot into OS and see the login screen
Actual: "Operating system is not found"

[1] http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.0-i386-disk.vmdk

[Shawn Hartsock (hartsock)]

Not low hanging fruit, but definitely simpler than some of the other bugs. This one is probably an order of operations error dealing with the order in which the disk is copied and the volume is mounted. This won't be complicated but it will take someone spending several hours with a practical testing environment to figure out what we should be writing a unit test to catch.

[Eric Brown (ericwb)]

I was unable to reproduce. I did the following:
1) glance image-create --name cirros-sparse --is-public=True --container-format=bare --disk-format=vmdk --property vmware_disktype="sparse" < cirros-0.3.0-i386-disk.vmdk
2) Created a volume from this image using Horizon
3) Booted from this new volumen using Horizon

We believe this was fixed with some unknown patch.

[Sreeram Yerrapragada (syerrapragada)]

I was able to reproduce the bug using image: https://www.dropbox.com/s/793n37blb4ra3t6/disk-vmdk.vmdk

[Eric Brown (ericwb)]

Here's the command used to reproduce using image from Sreeram:
glance image-create --name mono-sparse-ide --is-public=True --container-format=bare --disk-format=vmdk --property vmware_disktype="sparse" --property vmware_adaptertype="ide" < disk-vmdk.vmdk

[Eric Brown (ericwb)]

I opened a cinder bug, https://bugs.launchpad.net/cinder/+bug/1284284 which I believe is causing part of the problem.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/79087

[Tracy Jones (tjones-i)]

Eric - the cinder bugs have been merged. Is this still an issue?

[Tracy Jones (tjones-i)]

moving this back to triaged as the patch has been abandoned. please set to in progress when you start working on it again.

[Thang Pham (thang-pham)]

This is related to bug #1226543. It is fixed by https://review.openstack.org/#/c/122251/.

[Matthew Booth (mbooth-9)]

This bug doesn't appear to be related to bug #1226543 or the above change. It was fixed by https://review.openstack.org/#/c/124010/.

I have confirmed that I can reproduce the bug using the steps described here in the commit immediately prior to the above, but not when including the above change.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/152556

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/152556
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4b46a86f8a2af096e399df8518f8269f825684e0
Submitter: Jenkins
Branch: stable/icehouse

commit 4b46a86f8a2af096e399df8518f8269f825684e0
Author: Matthew Booth <email address hidden>
Date: Thu Sep 25 11:33:49 2014 +0100

    Fix image metadata returned for volumes

    When creating a volume from a glance image, cinder stores the original
    image metadata in volume_glance_metadata. This is a key/value store,
    and all the values are strings.

    When Nova boots an instance from a volume, it passes the image
    metadata returned by cinder, which is all strings. If a driver
    expects these values to be ints, as they are when booting from an
    image, it will get a type error.

    This change also pulls size from the volume directly rather than
    taking the value from the stored image metadata. This is because the
    volume will have been created in 1Gb increments, and is unlikely to be
    the same size as the original image. It may also have been
    subsequently extended.

    (cherry picked from commit 688be19e8a2170276451926401af8257c4faece5)

    Conflicts:
     nova/compute/api.py
     nova/tests/compute/test_compute.py

    Change-Id: I7928f6be1ca99f1502941b9df2b443f2ca63a37b
    Closes-Bug: #1367540
    Closes-Bug: #1255317