目录
Nova boot from volume
众所周知，Nova Launch Instance 有很多种方法，boot from image、boot from volume、boot from snapshot 等等。一般的我们在测试环境中大多会选择第一种方法，因为属于常规的操作方式。但实际上 boot from image 在生产环境中会存在一些限制，比如说：如果你在 boot from image 的同时选择启用了临时存储（Ephemeral Storage），这些临时的数据会随着 Instance 的生命周期结束而消失。所以一个产品化的 OpenStack 通常会将 boot from volume 作为默认选项，这样的好处在于增量的数据不会随着 Instance 的生命周期结束而消失。这些增量的数据是 Persistent 的，即便 Instance 被删除了 Volume 依旧可以被保存下来。无论是 boot from volume 还是 boot from snapshot 简单来说就是通过一个 bootable volume 启动操作系统。当然了，boot from volume 也存在一些限制：
- 一个 Volume 只能够一个 Instance 使用。不过随着 Rocky 版本 Cinder Multi-Attach 功能的发布，这个问题被缓和了许多。Multi-Attach 支持将同一个 Volume 挂载到多个不同的 VM，支持将一个 Volume 同时挂载在两个 VM 上，多台 VM 共享一个 Volume。当然了，这个功能我们更加建议将其使用到 Data Volume 而非 Bootable Volume 中。
- Boot from Volume 的 Instance 无法使用 Rebuild 功能。
Rebuild Instance
Rebuild Instance，顾名思义被用于重建 Instance。所谓重建，既有重新构建的意义、也具有修复的含义。当一个 Instance 出现故障而无法启动或正常使用的时候或者你希望更改 Instance GuestOS 类型的时候都可以考虑使用这个功能。
Rebuild Instance 的底层逻辑是在保留 Instance Flavor、Network、Configuration、Metadata 等信息不变的情况下，将在 Instance 在 ComputeNode 中的虚拟机实例进程 kill 掉。然后再根据提供的 Image 和原有的 instance 信息重建一台健康的虚拟机实例。可以保证 Instance 元数据（软件及其配置视乎于实际情况可能会丢失）和系统盘数据不变的前提下修复 Instance 或者对 Instance 的系统盘进行变更。
Rebuild for boot from volume
在 N 版本之前「Rebuild from boot from volume」被定义为一个 Bug，因为对 boot from volume 的 instance 无法通过 rebuild 功能将 new image 作为新的 boolable，在最近的版本中甚至将「Rebuild from boot from volume」作为强制禁止执行的动作。实话说，这个决定让人感到遗憾，正如前文所说，boot from volume 基本上是所有生产环境中的选择，无法进行 rebuild 则让 instances 缺失了一种重要的故障修复方式。
我们首先来看看造成这个问题的原因：实际上 Boot from image 的 rebuild 走的依旧是 Boot from image 的流程，拉取 new image 然后启动虚拟机；同样的，Boot from volume 的 rebuild 也依然走的是 boot form volume 流程，所以即便指定了 rebuild 的 new image，但它还是会将 old volume 挂载然后启动虚拟机，也就没能实现 boot from new image 的效果。
解决这个问题的思路：在 nova-compute service 进行 rebuild 的过程中捕获 boot from volume 特征的 instances，然后调用 Cinder 的接口将 new image 注入到 old volume 中，再使用 old volume 作为系统盘启动虚拟机实现 boot from new image 的 rebuild 效果。
这种实现方式基本上可以解决这个问题。