原始磁盘镜像（不带内核和启动盘的虚拟机镜像）

背景

曾经，半虚拟化的 Xen 依赖于特殊的内核，并且巧妙地实现了在没有完全硬件支持的情况下进行虚拟化。从那时起，芯片中的完全硬件支持变得更加普及，单独的启动盘和内核镜像在技术上不再是必需的。

这个蓝图旨在讨论启用此功能的调整。

NASA 可能有一些持续的业务需求需要内核/启动盘？

目前，如果在注册镜像时未指定内核/启动盘，并且在启动实例时也未指定内核/启动盘，则它将不带内核/启动盘启动。这样仍然与 euca-tools 兼容。

vish：无需内核启动的逻辑可能需要更改。我们可能需要一个标志来允许在不指定内核的情况下启动，也许是全局的，或者是在镜像存储中的每个镜像的。

justinsb：是的，这只是一个技巧，让我能够使其与 euca-tools 协同工作。有没有更好的旁路可以使用 euca-tools（在我们拥有自己的工具之前）？目前还不错…… 如果在镜像注册或实例启动时都没有指定内核，它会假定没有内核，因此这是一个完整的磁盘镜像。

justinsb：目前的方式是否存在“需求”问题，还是说这只是一个有点粗糙的技巧？

目前，在启动磁盘之前，它会被挂载（作为环回设备，这意味着主机必须了解客户机文件系统），然后文件会被注入到其中。目前这有点乱七八糟，硬编码过多！

此外，所做的一些修复可能不应该在这里进行——其中一些实际上是镜像构建中的错误。

vish：我推送了一个名为 mac-fix 的修复，它阻止了 udev 设置持久规则。这可能会使您原始磁盘镜像中的 remove-udev 规则参数变得过时。

justinsb：谢谢…… 我认为 remove-udev 规则的部分可能是因为我在打包镜像时犯了错误（留下了旧的规则文件），并且发现以这种方式修复起来更容易。我被建议应该简单地将网络 udev 规则文件作为镜像构建的一部分删除。

justinsb：因此，这可能与一个更大的争论有关，即应该在镜像中完成什么，以及在“启动虚拟机”阶段完成什么。启动虚拟机阶段对我来说很方便，但它可能无法处理其他操作系统，甚至其他发行版。

justinsb：一种可能性是有一个脚本可以修复常见的错误，可以在上传镜像之前运行。这甚至可以执行非常巧妙的操作，例如弄清楚更改的精确字节偏移量，以便我们可以将数据注入到我们不真正理解的文件系统（例如 Windows？）

justinsb：如果您同意，我可能会将我的一些更有问题的功能移动到一个新的脚本中。例如，我不认为模块加载必然属于那里；我只是在修复我自己的错误。但其他人也会犯同样的错误，因此使其易于操作是必要的。

vish：此外，我快速地添加了网络注入。我认为注入代码应该接受一个任意的字典列表，代表文件位置、所有者和组以及数据。然后您可以传入所需的任何内容，而无需添加参数列表

justinsb：我同意您可能已经将该函数推到了参数数量的极限 :-)

justinsb：对我来说，不清楚这个操作系统/发行版特定的知识是否应该超出磁盘注入函数。也许在理想的世界中，这种映射应该作为镜像上传的一部分提供。任何自动检测代码都可能很快变得混乱，因此将这种混乱包含在一个类/一组类中是有意义的。