VMware: boot from sparse image results in OS not found

[Eric Brown]

I am attempting to boot an instance from the cirros image found here: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk

So I originally imported the image without setting any of the vmware properties. So when I go to boot from this image, I get "Operating System not found" in the VM.

This was my user error, so I then used the glance command line image-update to set those properties after the image was already created. Then I tried another boot from this image. I got the same result, "Operating System not found".

However, if I set the properties for the image at image-create time, everything works. It also works if I do not boot the image before doing an image-update. So definitely seems as though some of the metadata is cached.

To Recreate:
- use glance image-create to import image: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk (do not set any of the vmware_* properties.
- boot from this image, notice it fails to find the OS as expected
- use glance image-update to modify the image metadata so that it properly has the --property vmware_adaptertype="ide" --property vmware_disktype="sparse" set.
- boot from this image again, notice it still fails, which is unexpected.

[Giridhar Jayavelu (gjayavelu)]

I hit this issue as well. It is time consuming for large images to re-create them with correct disk type.
Currently, we look for cached image file and if it exists we proceed without creating sparse image and continue using the flat image. I'm thinking we can address this by appending disk type in the cached image folder name. That way, a new folder and sparse image will be created.

[OpenStack Infra (hudson-openstack)]

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

[Giridhar Jayavelu (gjayavelu)]

I looked at this issue further. Though I was able to create new cache images based on disk type, the code for cache management required changes too.

Currently, vmware cache management looks at the list of used images and list of directories (which are named using image id) to mark images for deletion. In order to make cache management work properly, we need to override _list_running_instances() method and append disk type to image_ref_str.

Given that, I'm not sure if it is right approach to handle user error (specifying wrong disk_type) reported in this bug.
But I think it would be nice to _prevent_ such user error by introspecting the image and throw error if the disk_type doesn't match.

[Radoslav Gerganov (rgerganov)]

+1 for using image introspection for handling these types of user error. Also I don't think that changing the naming scheme for the cache is the right approach. It adds more complexity and impacts the upgrade.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/227104
Reason: This patch has been idle for a long time, so I am abandoning it to keep the review clean sane. If you're interested in still working on this patch, then please unabandon it and upload a new patchset.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY