[openstack-dev] [Nova] How boot with bdm_v2={source_type=image, destination_type=local} should been used?

Feodor Tersin ftersin at hotmail.com
Wed Feb 8 11:11:05 UTC 2017

HI Zhenyu

You're referring to API doc, but you're checking it with nova cli, which does not do exactly that what you want. In the case when you specify image and block-device parameters, nova cli sends image_ref and two (!) bdms. Both these bdms have the same boot_index and conflict with each other.

AFAIK nova cli adds the bdm for specified image_ref (not always, though).

In other words if you want to check API in this case, use pure curl instead of nova cli to avoid these implicit behavior. Or you may use write tests on Python using nova client.

From: Zhenyu Zheng <zhengzhenyulixi at gmail.com>
Sent: Wednesday, February 8, 2017 12:47:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Nova] How boot with bdm_v2={source_type=image, destination_type=local} should been used?

Hi All,

As I was working on "Check destination_type when booting with bdm provided": https://review.openstack.org/#/c/402372/ and addressing reviewers comments, I find out that the current source_type=image, destination_type=local seems unusable.

According to docs: http://docs.openstack.org/developer/nova/block_device_mapping.html#block-device-mapping-v2, it seems to me that "image --> local" means "boot from image", and as the doc says, I should also provide image_ref param, but if I do so, Error raised:

ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid. (HTTP 400) (Request-ID: req-f848c6c1-0961-46c4-ac51-713fde042215)

If I just use bdm, it goes:
2017-02-08 11:04:24.929 24141 ERROR nova.compute.manager [instance: 6e44cafd-b330-4a10-8c77-eac60d58f20c] ImageNotFound: Image could not be found.

turned out we use '' as image ID to fetch image from glance, and obviously we cannot get it.

Detailed Log and explaination could be found in my bug report:

So, what do we expect for this API usage?

Kevin Zheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170208/7ac3b199/attachment.html>

More information about the OpenStack-dev mailing list