我最近偶然看到了微软关于在云环境中配置逻辑卷管理 (LVM) 的建议，我觉得有些令人费解。该建议指出，虽然可以在连接到虚拟机 (VM) 的任何磁盘上配置 LVM，但大多数云映像默认情况下不会在 OS 磁盘上配置 LVM。提供的理由是，如果 OS 磁盘连接到同一分布和类型的另一个 VM，尤其是在恢复场景中，则可防止出现重复卷组问题。因此，该建议建议仅在数据磁盘上使用 LVM。
但是，我很难理解将操作系统磁盘连接到另一台虚拟机的实用性，尤其是考虑到故障排除和诊断任务可以轻松地在单独的虚拟机实例上执行。在数据恢复的情况下，启动没有 LVM 分区的新虚拟机并安装 LVM 卷似乎是一个简单的解决方案。
此外，由于 LVM 的僵化性而使用标准分区的理由似乎也不太令人信服。LVM 在管理磁盘空间方面提供了灵活性，与标准分区相比，可以更轻松地扩展卷，如果卷位于其他分区之间，这尤其有益。
我很好奇是否有人可以深入了解在云环境中将操作系统磁盘连接到另一台虚拟机是否必要或有利的场景。根据我的经验，分离系统和数据磁盘并将数据磁盘连接到新虚拟机是一种更实用的方法。
我很感激其他人对这个话题的任何见解或经验。
答案1
总结：LVM 在 VM 中是多余的。
这样做的理由是，如果操作系统磁盘曾经连接到同一分布和类型的另一个虚拟机，特别是在恢复场景中，则可以防止出现重复卷组问题。
这看起来确实像是一种货物崇拜推理。我遇到过一些将虚拟磁盘从一个虚拟机移动到另一个虚拟机的情况，但那始终是一个数据磁盘；例如，那是我们的升级路径：我们用虚拟数据磁盘准备新版本的虚拟机，当它准备好时，只需将旧虚拟机中的真实数据磁盘插入其中即可。
我几乎不记得有虚拟机被搞得这么糟糕以至于无法启动。无论如何，在这种情况下，从备份中恢复或完全重新配置虚拟机肯定比将系统磁盘安装到另一台虚拟机上来修复某些问题更合适。
此外，由于 LVM 的僵化性而使用标准分区的理由似乎也不太令人信服。LVM 在管理磁盘空间方面提供了灵活性，与标准分区相比，可以更轻松地扩展卷，如果卷位于其他分区之间，这尤其有益。
当您在虚拟机中运行时，您已经拥有一些虚拟机外部的卷管理。呈现给它的磁盘已经是虚拟的并且非常灵活；您不需要浪费任何资源来支持额外的冗余设施。（不仅运行时转换层很浪费，而且在虚拟机内监视和管理它的需求也需要资源。）
考虑一下这个想法的延续：您不在 VM 内构建软件 RAID 和多路径，而是在主机上构建；现在，您甚至不在 VM 内构建卷管理，而是在主机上构建。
因此，虚拟机的磁盘使用方式往往与裸机服务器不同。您无需添加一个或几个大磁盘并在虚拟机中对其进行分区，而是将每个潜在卷添加为最多包含一个分区的单独磁盘。当您需要扩展空间时，您可以在虚拟化环境中增加虚拟磁盘，然后在虚拟机中增加分区和 FS。这就是您的 LVM。
在大多数情况下，您将需要根文件系统和数据文件系统，例如两个虚拟磁盘，并且大约 30 GB 的根文件系统磁盘可能永远不需要调整大小。数据库通常建议使用单独的存储来存储预写日志；无论如何，这都需要添加专用的虚拟磁盘，因此将其放置在虚拟化环境中的单独存储上。
有几次我使用了超过四个虚拟磁盘，但所有这些情况都是由于某些人的糟糕计划而导致的，最终这些系统用更少的磁盘进行了重构。
答案2
该建议指出，虽然可以在连接到虚拟机 (VM) 的任何磁盘上配置 LVM，但大多数云映像默认不会在 OS 磁盘上配置 LVM。这样做的理由是，如果 OS 磁盘连接到同一分布和类型的另一台 VM，尤其是在恢复场景中，则可防止出现重复卷组问题。因此，该建议建议仅在数据磁盘上使用 LVM。
如果您从同一个基础映像创建两个虚拟机，并且该基础映像使用 LVM，然后将该基础映像覆盖的磁盘从一个虚拟机附加到另一个虚拟机：
- 该磁盘上的任何 PV 都将具有与系统中现有磁盘上相应 PV 相同的 UUID。具有重复 UUID 的 PV 将在发现 VG 期间引起问题，因为 LVM故意地仅在内部使用 UUID 来识别 PV（这样做是为了让您不必担心 PV 显示为哪个设备节点），并且它不知道在具有相同 UUID 的 PV 中对于给定的 VG 要使用哪个 PV。
- 该磁盘上的任何 VG 都将具有相同的 UUID和将其命名为系统中现有磁盘上的相应 VG。根据 LVM 版本和配置，这将导致它们被合并，或者两者都拒绝激活，或者可能只有第一个发现的 VG 被激活。
同样的问题也可能发生在常规系统中，但除非您定期进行克隆系统之类的操作，否则这种情况并不常见。
它可以还成为文件系统级别的问题（文件系统的重复 UUID 可能会产生严重的问题），但这通常只是启动时的问题，除非您使用 BTRFS，而且在大多数情况下很容易解决，因为您可以选择通过标签或设备来识别文件系统。
此外，由于 LVM 的僵化性而使用标准分区的理由似乎也不太令人信服。LVM 在管理磁盘空间方面提供了灵活性，与标准分区相比，可以更轻松地扩展卷，如果卷位于其他分区之间，这尤其有益。
您实际上多久会需要调整分区大小？虚拟机的标准不是在一块巨型磁盘上有几十个分区，而是在系统磁盘上有一到三个分区（如果需要，还有固件启动卷，可选的/boot，以及根分区），任何数据卷都是独立的，投入的磁盘。
因为除了系统磁盘之外的所有磁盘的标准都是每个磁盘一个分区，所以 LVM 在系统磁盘之外的任何地方都没有什么价值（因为要调整这些分区的大小，你本质上需要调整磁盘本身，这在 VM 设置上通常很容易）。而对于系统磁盘，很少需要调整任何分区的大小（固件启动卷通常是固定大小，/boot在大多数情况下最多可能是 1G，而根分区将是磁盘的其余部分），所以这没什么价值。
答案3
我对 Azure 上的流程不是特别熟悉，但使用 qemu 和在 AWS 上，调整卷大小的过程比设置 PV/LV 简单得多。
需要将操作系统磁盘附加到云环境中的另一台虚拟机的场景
因为 /boot 乱了？或者单用户模式有密码保护，而你没有密码。
答案4
有一种用例是“将操作系统磁盘连接到云环境中的另一个虚拟机是必要的或有利的”。有时，人们会错误配置虚拟机，导致无法访问它。正常的解决方法是删除虚拟机并重试，但有时这不是一个选择。
为此，OpenStack 有一个“救援模式”。它确实通过将获救虚拟机的操作系统磁盘连接到已知正常工作的其他虚拟机来工作。在此状态下，您可以检查损坏的虚拟机的磁盘并尝试修复其配置。通常，这意味着创建一种从控制台登录的方式，使用密码，或者如果网络配置不是需要修复的问题，则向某个用户添加 ssh 密钥。