)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6a9bbd827ea624cb32e67d0174de5d6fca6a04b3","unresolved":true,"context_lines":[{"line_number":22,"context_line":"os boot device mechanism for backward compatibility."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"[1] https://github.com/coreboot/seabios/commit/2f4d068645c211e309812372cd0ac58c9024e93b"},{"line_number":25,"context_line":"[2] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1924972"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Closes-Bug: #2127229"},{"line_number":28,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":11,"id":"9d4bbf2c_ea0cddbe","line":25,"updated":"2026-01-13 14:59:57.000000000","message":"we have a soft rule that we shoudl not specify bugzilla or jira link in commit messages\n\nin geneal those should be place in the launchpad bug.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"eb8672fe9454391ef290054a7c10047d2902e606","unresolved":false,"context_lines":[{"line_number":22,"context_line":"os boot device mechanism for backward compatibility."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"[1] https://github.com/coreboot/seabios/commit/2f4d068645c211e309812372cd0ac58c9024e93b"},{"line_number":25,"context_line":"[2] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1924972"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Closes-Bug: #2127229"},{"line_number":28,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":11,"id":"f8ae04bd_f36ff7ab","line":25,"in_reply_to":"9d4bbf2c_ea0cddbe","updated":"2026-03-10 10:55:34.000000000","message":"Done","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6a9bbd827ea624cb32e67d0174de5d6fca6a04b3","unresolved":true,"context_lines":[{"line_number":24,"context_line":"[1] https://github.com/coreboot/seabios/commit/2f4d068645c211e309812372cd0ac58c9024e93b"},{"line_number":25,"context_line":"[2] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1924972"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Closes-Bug: #2127229"},{"line_number":28,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"},{"line_number":29,"context_line":"Signed-off-by: Seyeong Kim \u003cseyeong.kim@canonical.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":11,"id":"93468b14_15cfe5e8","line":27,"updated":"2026-01-13 14:59:57.000000000","message":"i replied on the bug but this feels more like a feature request then a bug\neffecitlvy you are tryign to supprot boot form volume with multipel boot volumes which is not supproted today.\n\nboot from voluem is only supported for the root disk.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"eb8672fe9454391ef290054a7c10047d2902e606","unresolved":false,"context_lines":[{"line_number":24,"context_line":"[1] https://github.com/coreboot/seabios/commit/2f4d068645c211e309812372cd0ac58c9024e93b"},{"line_number":25,"context_line":"[2] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1924972"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Closes-Bug: #2127229"},{"line_number":28,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"},{"line_number":29,"context_line":"Signed-off-by: Seyeong Kim \u003cseyeong.kim@canonical.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":11,"id":"e5e00243_5b474ee4","line":27,"in_reply_to":"93468b14_15cfe5e8","updated":"2026-03-10 10:55:34.000000000","message":"Acknowledged","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"60dbcc4bab30b853e649128ba63ffbac3725d22b","unresolved":true,"context_lines":[{"line_number":9,"context_line":"Nova drops bootindex on all but the first block device because it"},{"line_number":10,"context_line":"emits \u003cos\u003e\u003cboot dev\u003d\u0027hd\u0027/\u003e\u003c/os\u003e instead of per-device \u003cboot order/\u003e."},{"line_number":11,"context_line":"SeaBIOS skips devices without bootindex, so chainloaded boot between"},{"line_number":12,"context_line":"multi-boot disks fails."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Emit per-device \u003cboot order/\u003e when 2+ devices carry boot_index; the"},{"line_number":15,"context_line":"single-device case keeps the old os-level boot dev for backward compat."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":17,"id":"7787ea4c_01dfb8cb","line":12,"updated":"2026-06-11 10:27:40.000000000","message":"if you use the block device mapping api on sever create and only on sever create it is posibel to pass a boot index\n\n\nhttps://docs.openstack.org/nova/latest/user/block-device-mapping.html#block-device-mapping-v2\n\n```\nboot_index - Defines the order in which a hypervisor will try devices when attempting to boot the guest from storage. Each device which is capable of being used as boot device should be given a unique boot index, starting from 0 in ascending order. Some hypervisors may not support booting from multiple devices, so will only consider the device with boot index of 0. Some hypervisors will support booting from multiple devices, but only if they are of different types - eg a disk and CD-ROM. Setting a negative value or None indicates that the device should not be used for booting. The simplest usage is to set it to 0 for the boot device and leave it as None for any other devices.```\n\nsupprot for this was alwasy driver depented and not guranteed\n\nand because thsi coudl only be set vai the block device maping api during srever create it has never been possibelf for exampel to add cidner volume after the fact and boot form that\n\nwhich means the detach and attach case you mention before is explcity not supproted\nbecause when you attach a cidner volume you cannot set a boot index on it.","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"60dbcc4bab30b853e649128ba63ffbac3725d22b","unresolved":true,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Emit per-device \u003cboot order/\u003e when 2+ devices carry boot_index; the"},{"line_number":15,"context_line":"single-device case keeps the old os-level boot dev for backward compat."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Also keep \u003cboot order/\u003e on attach when the guest already uses"},{"line_number":18,"context_line":"per-device boot order, so detach + re-attach does not drop it."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Closes-Bug: #2127229"},{"line_number":21,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"},{"line_number":22,"context_line":"Signed-off-by: Seyeong Kim \u003cseyeong.kim@canonical.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":17,"id":"e9559f96_1cf7027b","line":19,"range":{"start_line":16,"start_character":1,"end_line":19,"end_character":1},"updated":"2026-06-11 10:27:40.000000000","message":"https://docs.openstack.org/api-ref/compute/#id195\n\nthe volume attachment api does not allwo you to set a boot index and we have never supprot booting form addtional data volumes that were added after the inital vm create.\n\nthat is the only way our api has ever supported seting the boot index.","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a6496ff31385b1e07e10a89df694765f66ae4dd0","unresolved":true,"context_lines":[{"line_number":17,"context_line":"Also keep \u003cboot order/\u003e on attach when the guest already uses"},{"line_number":18,"context_line":"per-device boot order, so detach + re-attach does not drop it."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Closes-Bug: #2127229"},{"line_number":21,"context_line":"Change-Id: I73c7cc7930d10aadf4ccc6c1a4f2fda50cace08c"},{"line_number":22,"context_line":"Signed-off-by: Seyeong Kim \u003cseyeong.kim@canonical.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":18,"id":"1c2de67b_b601ac5d","line":20,"updated":"2026-06-11 11:35:11.000000000","message":"digging into the history  https://blueprints.launchpad.net/nova/+spec/hyper-v-set-boot-order\nhttps://review.opendev.org/q/topic:bp/hyper-v-block-device-mapping-support\n\nthe only test i could find related to this in the libvirt drier are in \n\nhttps://opendev.org/openstack/nova/src/branch/master/nova/tests/unit/virt/libvirt/test_blockinfo.py\n\nwere we are just testing the block device maping processign and those mainly relate to rescuse or config drive cases..\n\nim not against having a feature to allow you nova to suprpot multipel boot souces  (local disk, cinder volume and ideally pxe over neutron ports) nor am i against reopening the idea fo eventually supproting detaching boot volumes but i dont think it make ssense to partly enable it vai a bug fix.\nhence maintianing my -1","commit_id":"7437eb7ff932db0276423f32359ba0deb8e2d0e2"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"0cf95beb2ba0a700f850da7c762d9dc0c57f46f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"8f352a36_a2066dbc","updated":"2025-11-25 05:04:14.000000000","message":"recheck Timed out waiting for controller compute service to be enabled","commit_id":"87da16b4ae794272062386e8847f07281d1c5099"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"f28fd071f77217bfee5944847f7af8b2acd1f23f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"00cf585a_092c47e4","updated":"2025-12-08 00:51:58.000000000","message":"Hello, I added you as a reviewer for this patch.\nIf you have some time, I would be grateful if you could review it,\nand any suggestions on improving the current approach would be much appreciated.\nRight now the logic checks the number of disks and sets the \u0027boot\u0027 option conditionally.\nThank you for your guidance and help.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6a9bbd827ea624cb32e67d0174de5d6fca6a04b3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":11,"id":"a6ada407_6ad8329a","updated":"2026-01-13 14:59:57.000000000","message":"while the current api imples you cah have multipe boot disk we do not documetn or test that today. to me suprpotign that properly with multiple cinder boot volumes need more testing and docuematnion is is more of a feature then a bug.\n\nat a miminium this patch needs a release note, documeation and ideally we woudl have functional testcoverage.\n\ni dont think unit test are sufficent for this.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"e670e17dba77ce0b41c23f6b6c0550dc02d4db29","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"7ed40ae7_cb343469","in_reply_to":"a6ada407_6ad8329a","updated":"2026-06-05 03:00:20.000000000","message":"Done","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"aa511143d7708ac6f446ea21b83ed5afe4ec9bd9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"81ecb30c_f380711b","updated":"2026-01-27 05:16:48.000000000","message":"recheck","commit_id":"4eff4cbd5d6aa82c26b682749b4d9ff3d92b3397"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"49fc0b0623944c8fc5fc2061eed10c7ea9cdf004","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":16,"id":"722901f9_ca182c5e","updated":"2026-06-08 05:43:01.000000000","message":"@smooney@redhat.com By the way, I realized I had not explained this clearly enough, either in Launchpad or here. I think I briefly mentioned it in an earlier patch set, but the explanation probably did not include enough context.\n\nThis use case previously worked with libvirt/qemu because SeaBIOS would try to boot from every device as a fallback. That behavior later changed, which broke a real use case for one of our users.\n\nSo while this is new from Nova\u0027s perspective, it is also restoring functionality that used to work by accident. I added the full details to the Launchpad bug.\n\nThanks.","commit_id":"85babc48824750ea5fbabe488236aa40bf1c5a59"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"41d0a6863055fed814352bd838b16f86ddaf31d2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":16,"id":"b0242989_0a7ff009","updated":"2026-06-05 04:56:36.000000000","message":"Although the original meaning of `boot_index` may have been different, I still think this patch is worth considering. From a user’s perspective, it is reasonable to expect multiple `boot_index` values to be honored when creating an instance or attaching/detaching multiple bootable volumes. Could you please take another look at this patch?","commit_id":"85babc48824750ea5fbabe488236aa40bf1c5a59"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"5e766e27752549afb07f4cad540dd5dbd3e92567","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":16,"id":"dc250e7f_c8bb56ba","updated":"2026-06-04 06:48:28.000000000","message":"recheck","commit_id":"85babc48824750ea5fbabe488236aa40bf1c5a59"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"3f38a20587631f3824ccae716c683138b0bc6b08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"283c43af_0a064fb6","updated":"2026-06-09 15:31:42.000000000","message":"Just one question, looks good otherwise.","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"f957dffe01ae108f60a5c92f65fa7acf656768a4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"e759b6e4_a87837ae","updated":"2026-06-09 09:32:24.000000000","message":"recheck","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"60dbcc4bab30b853e649128ba63ffbac3725d22b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":18,"id":"58b8036c_d0aa4e1d","updated":"2026-06-11 10:27:40.000000000","message":"i gave this feedback when i first triage this bug as whisilist hat this really is a feature and shoudl be deisgiend via the spec process not as the bug.\n\n\nwe have rejected allwoing detaching bootable root volumes in the past several times\n\nthis is proapsing a way to do that as a side channel without an api for it which is not approates.\n\nvia this appoch you would be able to create a vm with an empty root disk\nadd multipel addtional boot disk with a higher precedience and then\ndetach adn atach them at will.\n\nif we wreally want to supprot that we need to properly design it.","commit_id":"7437eb7ff932db0276423f32359ba0deb8e2d0e2"}],"doc/source/user/launch-instance-from-volume.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"60dbcc4bab30b853e649128ba63ffbac3725d22b","unresolved":true,"context_lines":[{"line_number":437,"context_line":""},{"line_number":438,"context_line":"   When using multiple bootable block devices with ``boot_index``, be aware"},{"line_number":439,"context_line":"   that ephemeral disks are local to the compute node. Data on ephemeral"},{"line_number":440,"context_line":"   disks may be lost during shelve/unshelve or evacuate operations. For"},{"line_number":441,"context_line":"   data persistence, use Cinder volumes instead of ephemeral disks."},{"line_number":442,"context_line":""},{"line_number":443,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":18,"id":"a2489d65_ff0f5934","line":440,"updated":"2026-06-11 10:27:40.000000000","message":"and during rebuild and resize\n\nmarkign a epmeral disk as bootable shoudl be considerd a hard error and rejected in the api.","commit_id":"7437eb7ff932db0276423f32359ba0deb8e2d0e2"}],"nova/tests/functional/libvirt/test_boot_order.py":[{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"3f38a20587631f3824ccae716c683138b0bc6b08","unresolved":true,"context_lines":[{"line_number":173,"context_line":"            o for o in self._get_attached_disk_boot_orders(server_id)"},{"line_number":174,"context_line":"            if o is not None]"},{"line_number":175,"context_line":"        self.assertEqual("},{"line_number":176,"context_line":"            {\u00271\u0027, \u00272\u0027}, set(initial_orders),"},{"line_number":177,"context_line":"            \u0027spawn should set per-device boot order on both volumes\u0027)"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"        # Detach the non-root bootable volume (boot_index\u003d1)."}],"source_content_type":"text/x-python","patch_set":17,"id":"116e1b93_3edd332f","line":176,"updated":"2026-06-09 15:31:42.000000000","message":"Only asking since I noticed this is not a list like the two below - will there be multiple identical values here?","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"e6cce7b73a82eed1dcc6f55756fbdcceb176fec2","unresolved":false,"context_lines":[{"line_number":173,"context_line":"            o for o in self._get_attached_disk_boot_orders(server_id)"},{"line_number":174,"context_line":"            if o is not None]"},{"line_number":175,"context_line":"        self.assertEqual("},{"line_number":176,"context_line":"            {\u00271\u0027, \u00272\u0027}, set(initial_orders),"},{"line_number":177,"context_line":"            \u0027spawn should set per-device boot order on both volumes\u0027)"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"        # Detach the non-root bootable volume (boot_index\u003d1)."}],"source_content_type":"text/x-python","patch_set":17,"id":"d4943c49_49c51783","line":176,"in_reply_to":"116e1b93_3edd332f","updated":"2026-06-11 10:12:13.000000000","message":"Thanks, my bad. fixed it.","commit_id":"f50d3a5a92a8622104ba4d48c030c526b7017fed"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"60dbcc4bab30b853e649128ba63ffbac3725d22b","unresolved":true,"context_lines":[{"line_number":146,"context_line":"        domain \u003d conn.lookupByUUIDString(server_id)"},{"line_number":147,"context_line":"        return [d.get(\u0027boot_order\u0027) for d in domain._def[\u0027devices\u0027][\u0027disks\u0027]]"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"    def test_detach_attach_preserves_multiple_boot_order(self):"},{"line_number":150,"context_line":"        # After detach+attach of a non-root bootable volume, the re-attached"},{"line_number":151,"context_line":"        # disk must still carry a \u003cboot order/\u003e. Otherwise SeaBIOS skips"},{"line_number":152,"context_line":"        # initializing the device and chainloaded boot from the root disk"}],"source_content_type":"text/x-python","patch_set":18,"id":"56603993_b17fed26","line":149,"range":{"start_line":149,"start_character":6,"end_line":149,"end_character":62},"updated":"2026-06-11 10:27:40.000000000","message":"so we do not supprot detachign boot devices\n\nthis is why we do not allow you to detach teh root disk when you boot form a cinder voluem\n\nthis really feals like an attpetn to woraouhnd the fact we do not allow that.\n\nit would be incorrect to try and perseve the booto order lieki this when we detach the volume as no refence ot that voluem shoudl remain in the vm block device maihng and we do not aloow you to pass the boot index when attaching a volume in the api.\n\n\nwhatever leway there is about the rest of the change being condier a bug this is a new feature.","commit_id":"7437eb7ff932db0276423f32359ba0deb8e2d0e2"}],"nova/virt/libvirt/volume/volume.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6a9bbd827ea624cb32e67d0174de5d6fca6a04b3","unresolved":true,"context_lines":[{"line_number":118,"context_line":"        # handling conf.boot_order is already implemented."},{"line_number":119,"context_line":"        # e.g openstack server create ..."},{"line_number":120,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d0"},{"line_number":121,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d1"},{"line_number":122,"context_line":"        if ("},{"line_number":123,"context_line":"            \u0027boot_index\u0027 in disk_info and"},{"line_number":124,"context_line":"            disk_info.get(\u0027use_device_boot_order\u0027, False)"}],"source_content_type":"text/x-python","patch_set":11,"id":"9e44f7f2_3a06ebe2","line":121,"updated":"2026-01-13 14:59:57.000000000","message":"so this is not currently supproted.\n\ni belive if you chaeck the created volume in cinder you would see the second volume is not marked as bootable.\n\nnova has multiple way to boot form a cidner volume\n\nthe first is \"Create a volume from an image and boot an instance from that volume\"\n```\nopenstack server create \\\n    --flavor $FLAVOR --network $NETWORK \\\n    --image 44d317a3-6183-4063-868b-aa0728576f5f --boot-from-volume 10 boot-from-nova-created-volume\n```\nor \n```\n openstack server create \\\n    --flavor $FLAVOR --network $NETWORK \\\n    --block-device source_type\u003dimage,uuid\u003d44d317a3-6183-4063-868b-aa0728576f5f,destination_type\u003dvolume,size\u003d10,boot_index\u003d0 boot-from-nova-created-volume\n```  \n    \n    \nthere is also a second variant of this flow which ius \n\"Create a volume from an volume snapshot and boot an instance from that volume\"\n\n```\n openstack server create \\\n    --flavor $FLAVOR --network $NETWORK \\\n    --block-device source_type\u003dsnapshot,uuid\u003d44d317a3-6183-4063-868b-aa0728576f5f,destination_type\u003dvolume,size\u003d10,boot_index\u003d0 boot-from-nova-created-volume\n```  \n\ncreating the root disk form a image or snapshot is what most peopel think of when booting form volumes and is only supported for a single boot volume today.\n\nthe second flow is \"booting a VM form an existing volume\"\n```\nopenstack volume create \\\n    --image 44d317a3-6183-4063-868b-aa0728576f5f --size 10 \\\n    test-volume\n    \nopenstack server create \\\n    --flavor $FLAVOR --network $NETWORK \\\n    --volume 9c7f68d4-4d84-4c1e-83af-b8c6a56ad005\\\n    --wait boot-form-existing volume\n```\n\nyou can also do that with --block-device\n\n```\nopenstack volume create \\\n    --image 44d317a3-6183-4063-868b-aa0728576f5f --size 10 \\\n    test-volume\n    \nopenstack server create \\\n    --flavor $FLAVOR --network $NETWORK \\\n    --block-device source_type\u003dvolume,uuid\u003d\u003cvolume uuid\u003e,destination_type\u003dvolume,size\u003d10,boot_index\u003d0 boot-from-nova-created-volume\n```\n\nyou can boot form a pre created cinder volume\nhttps://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html\n\nwe do not actully documetn teh ablity to create a vm with mutli0ple bootable disk\ni beivle this was ofrignlly added for non libvirt backends.\n\nif you create the volumes manually and ensure that they are marked as bootable in cidner and pass those in it might eb possible to create a vime with 2 bootable voluems today but i think the orgings of the boot_index was orginally for rescue not as a generic feature.\n\nif we actully want to supprot creatign vms with multipe boot disks that to me is a feature not a bug.\n\n\nim not agains supproting that but we likely need to do a lot more testing and documentation changes then is propsoed in this patch.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7e4766d8d2fee0e12f1bf5e90c26b60dce95727","unresolved":true,"context_lines":[{"line_number":118,"context_line":"        # handling conf.boot_order is already implemented."},{"line_number":119,"context_line":"        # e.g openstack server create ..."},{"line_number":120,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d0"},{"line_number":121,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d1"},{"line_number":122,"context_line":"        if ("},{"line_number":123,"context_line":"            \u0027boot_index\u0027 in disk_info and"},{"line_number":124,"context_line":"            disk_info.get(\u0027use_device_boot_order\u0027, False)"}],"source_content_type":"text/x-python","patch_set":11,"id":"1d6628c8_a80befb0","line":121,"in_reply_to":"08d56482_5326602b","updated":"2026-01-16 10:57:50.000000000","message":"i think that is a bug but we dont have enough testing or docuemation fo this fucntionality to fully declare ti to be a properly supproted and tested Feature in the normal sence.\ni belive we inteded to suppot this functionality at some point in the past but clearly there are bugs in how that works.\n\nusing sata ro scisi may indeed be a workaround\nbringing parity to virtio-blk would fall in the catagory of a bug but as i noted env in the sata case teh existing fo this feature is pretty hidden.\n\ni triaged the bug as wishlist as it on the board between a feature and a bug btu i think we coudl likely proceed with it as a bug fix if we add sufficent testign and docs for how to do this to prevent regressiosn and inform users what to expect.\n\ni.e. that if you do this with ephmeral disk instead of cinder voluems you can lose data if you shelve the instance ectra.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"dce9824997ae7f6c89628ee2dfe44b05420a1bb9","unresolved":true,"context_lines":[{"line_number":118,"context_line":"        # handling conf.boot_order is already implemented."},{"line_number":119,"context_line":"        # e.g openstack server create ..."},{"line_number":120,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d0"},{"line_number":121,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d1"},{"line_number":122,"context_line":"        if ("},{"line_number":123,"context_line":"            \u0027boot_index\u0027 in disk_info and"},{"line_number":124,"context_line":"            disk_info.get(\u0027use_device_boot_order\u0027, False)"}],"source_content_type":"text/x-python","patch_set":11,"id":"429e2129_ce83807e","line":121,"in_reply_to":"1d6628c8_a80befb0","updated":"2026-03-03 11:15:47.000000000","message":"I have added some doc and test code after your recommendation. but not sure it is enough. do you think this commit can be merged? thank you so much for your review.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"e670e17dba77ce0b41c23f6b6c0550dc02d4db29","unresolved":false,"context_lines":[{"line_number":118,"context_line":"        # handling conf.boot_order is already implemented."},{"line_number":119,"context_line":"        # e.g openstack server create ..."},{"line_number":120,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d0"},{"line_number":121,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d1"},{"line_number":122,"context_line":"        if ("},{"line_number":123,"context_line":"            \u0027boot_index\u0027 in disk_info and"},{"line_number":124,"context_line":"            disk_info.get(\u0027use_device_boot_order\u0027, False)"}],"source_content_type":"text/x-python","patch_set":11,"id":"c154327b_7df849c9","line":121,"in_reply_to":"429e2129_ce83807e","updated":"2026-06-05 03:00:20.000000000","message":"Done","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"},{"author":{"_account_id":5112,"name":"Seyeong Kim","email":"seyeong.kim@canonical.com","username":"xtrusia"},"change_message_id":"c0dfaeeeb29d55df0672bf4822f3bda733a4d694","unresolved":true,"context_lines":[{"line_number":118,"context_line":"        # handling conf.boot_order is already implemented."},{"line_number":119,"context_line":"        # e.g openstack server create ..."},{"line_number":120,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d0"},{"line_number":121,"context_line":"        #     --block-device source_type\u003dsnapshot,uuid\u003d...,boot_index\u003d1"},{"line_number":122,"context_line":"        if ("},{"line_number":123,"context_line":"            \u0027boot_index\u0027 in disk_info and"},{"line_number":124,"context_line":"            disk_info.get(\u0027use_device_boot_order\u0027, False)"}],"source_content_type":"text/x-python","patch_set":11,"id":"08d56482_5326602b","line":121,"in_reply_to":"9e44f7f2_3a06ebe2","updated":"2026-01-16 08:27:46.000000000","message":"Thanks for the clarification, Sean. I understand your point about this being a feature request.\n\nI\u0027m curious about one aspect though. since boot_index already works correctly with sata bus(as a test) type but not with virtio, would this inconsistency in behavior between bus types still be considered a feature request rather than a bug fix? I\u0027d like to make sure I understand the distinction correctly.","commit_id":"e49fa4ed3c36989ba13d89e514aed5541ae46467"}]}