在KVM / libvirt主机和来宾之间共享LVM卷组:这是一个坏主意吗?


12

我刚刚构建了一个新的基于KVM / libvirt的闪亮虚拟机主机,其中包含4个SATA II硬盘驱动器,并运行CentOS 5.5 x86_64。

我决定将虚拟机磁盘创建为作为libvirt存储池管理的LVM卷组中的逻辑卷,而不是通常将磁盘创建为qcow映像的做法。

我无法确定是在VM主机的卷组中还是在专用卷组中创建虚拟机逻辑卷。

我应该选择哪种方法,为什么?


方法1:使用VM主机的卷组

实现方式:

  • md0包含/boot文件系统的小型RAID1
  • 大RAID10 md1占用剩余空间,其中包含LVM卷组vghostvghost包含VM主机的根文件系统和交换分区
  • vghost根据需要在逻辑卷中创建虚拟机磁盘

优点:

  • 如果VM主机的根文件系统空间不足,我可以vghost相对轻松地分配更多空间
  • 系统已经启动并且正在运行(但是重新开始没什么大不了的)

缺点:

尽管这种方法似乎行之有效,但我不能不觉得这是一个坏主意。我觉得:

  • 这可能会带来安全风险
  • 在将来的某个时候,我可能会对设置有所限制,并希望我使用一个专门的小组
  • 系统(CentOS,libvirt等)可能并非真正设计为像这样使用,因此在某些时候,我可能会偶然损坏/丢失VM主机的文件和/或文件系统

方法2:使用专用的卷组

实现方式:

  • 同样的md0,并md1在方法1,除了化妆md1只是大到足以容纳VM主机(如5至10GB)
  • 大RAID10 md2占用剩余空间。md2包含一个LVM卷组vgvms,其逻辑卷将由虚拟机专用

优点:

  • 我可以修补而vgvms不必担心破坏主机操作系统
  • 这似乎是一个更优雅,更安全的解决方案

缺点:

  • 如果VM主机的文件系统空间不足,则必须将其文件系统的某些部分(例如/ usr或/ var)移动到上vgvms,这看起来不太好。
  • 我必须重新安装主机操作系统(如前所述,我并不介意这样做)

更新#1:

我担心方法2中的VM主机磁盘空间不足的原因之一是因为我不知道VM主机是否足够强大,无法在虚拟机中运行所有服务。我可能必须将部分/全部服务从虚拟机迁移到主机OS。

VM主机硬件规格:

  • Phenom II 955 X4黑色版处理器(3.2GHz,4核CPU)
  • 2x4GB金士顿PC3-10600 DDR3 RAM
  • 技嘉GA-880GM-USB3主板
  • 4个WD Caviar RE3 500GB SATA II硬盘(7200rpm)
  • Antec BP500U Basiq 500W ATX电源
  • CoolerMaster CM 690机箱

更新#2:

我认为系统可能无法设计为在方法1中将主机VG用作libvirt存储池的原因之一是我在virt-manager中注意到的一些行为:

  • 添加后,它抱怨无法激活VG(显然是因为主机操作系统已经激活了它)
  • 删除后,它拒绝这样做,因为它无法停用VG(显然,因为主机OS仍在使用root和swap LV)

我提出了一个问题(#272324),您的解决方案#1将会是一个很好的答案!这正是我在类似设置中追求的目标-到目前为止,我对此感到非常满意。但是,我确实有一个问题,即Guest中的diskIO比“循环装入”主机中的同一LV慢得多。
stolsvik 2011年

Answers:


3

深思熟虑的问题!

我会使用方法2,但这更多是个人喜好。对我来说,方法2的缺点不是什么大问题。我不认为主机操作系统会超出其5-10GB分区,除非您开始在其上安装额外的东西,否则您确实不应该这样做。为了简单和安全起见,主机操作系统实际上应该是最小安装,除了运行管理所需的最小安装(例如sshd)外,不要运行任何东西。

方法1的缺点也不是问题,IMO。我认为不会有任何额外的安全风险,因为如果有根的VM能够以某种方式脱离其分区并感染/损坏其他分区,则将主机OS安装在单独的VG上可能不会有任何影响。我无法从直接的经验谈起其他两个缺点,但是我直言不讳地说CentOS,LVM和libvirt足够灵活和强大,不必担心它们。

编辑-对更新1的响应

如今,虚拟化对性能的影响非常低,尤其是使用内置支持虚拟化的处理器时,所以我认为将服务从来宾VM迁移到主机OS永远都不值得。通过在“裸机”上运行,您可能会获得10%的速度提升,但是您将失去拥有小型,紧凑,安全的主机OS的好处,并可能影响整个服务器的稳定性。IMO,这不值得。

鉴于此,我仍然倾向于方法2。

对更新2的回应

看来,libvirt假定对存储进行布局的特定方式是支持方法2的另一点。我的建议是:使用方法2。


谢谢。我在问题后附加了2个更新,这进一步解释了为什么我列出了您已经解决的一些缺点。更新是否完全改变了您的意见?
mosno 2010年

@mosno:更新了我的回答以响应您的更新。
史蒂文

感谢大家的回答,所有这些对我都有帮助,很难选择接受谁的答案。我之所以选择史蒂文斯,是因为我认为它已尽最大努力解决了所提出的问题。作为记录,虽然我同意方法2可能更好,但我选择保留方法1,因为它可以工作并且受时间限制。
mosno

1
另外,我现在仍然使用方法1,因为我认为探索这种方法的局限性是有教育意义的。例如,我了解到,如果您在来宾OS中直接在设备(例如,设备/ dev / vda而不是分区/ dev / vda1)上创建LVM PG,则主机OS的pvscan会列出来宾的PV(即。使用/ dev / vda1,而不是/ dev / vda)。
mosno

1

只要在任何时候只有一个系统尝试以读/写模式使用任何给定的LV,将相同的VG用于主机和来宾是可行的。如果多个系统尝试写入同一LV,则将导致文件系统损坏。


当然,管理此问题的复杂性水平不断提高。这很聪明..也许太聪明了。
Unix管理员

@ user37899:这是处理LVM的常用方法
Javier 2010年

谢谢,但我明白这一点;我不打算这样做。
mosno 2010年

当我在主机OS上执行“ lvscan”时,它将来宾的LV报告为“ ACTIVE”。主机未安装LV。LV是否仅处于“ ACTIVE”状态就构成“读/写模式”,还是意味着显式安装到主机的文件系统?
mosno

我的意思是显式的R / W安装。
伊格纳西奥·巴斯克斯

1

您可能想看看这个,也许是修补一下,看看这个项目如何完成您所谈论的事情。

ProxmoxVE是裸机KVM主机,它使用libvirt的perl实现,而不是RHEL的较重版本。它实现了两种情况。

虚拟磁盘是.raw和稀疏的,类似于.qcow,但是速度更快。

还支持qcow和vmdk磁盘映像格式,但我认为可能涉及LVM限制。我不使用它们,所以我不能多说。

LVM存储在节点上的VM之间共享,并且可以是DRBD设备。

至于共享OS的VG空间,唯一要注意的限制是备份期间的快照大小。在这里,可以在配置文件中更改此值,有时我在人们不得不对其进行更改的论坛中看到,但是默认设置已经为我服务了好几年了,即使使用巨大的虚拟磁盘也是如此。

PVE的LVM存储详细信息:

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

VG的布局是这样的:

使用元数据类型lvm2找到了卷组“ LDatastore1”

使用元数据类型lvm2找到了卷组“ LDatastore0”

使用元数据类型lvm2找到了卷组“ pve”

这些是我的LV:

ACTIVE'/ dev / LDatastore1 / vm-9098-disk-1'[4.00 GB]继承

活动'/ dev / LDatastore1 / vm-7060-disk-1'[2.00 GB]继承

活动'/ dev / LDatastore1 / vm-5555-disk-1'[8.00 GB]继承

活动'/ dev / LDatastore0 / vm-4017-disk-1'[8.00 GB]继承

活动'/ dev / LDatastore0 / vm-4017-disk-2'[512.00 GB]继承

活动'/ dev / LDatastore0 / vm-7057-disk-1'[32.00 GB]继承

活动'/ dev / LDatastore0 / vm-7055-disk-1'[32.00 GB]继承

ACTIVE'/ dev / LDatastore0 / vm-6030-disk-1'[80.01 GB]继承

活动的'/ dev / pve / swap'[3.62 GB]继承

活动的'/ dev / pve / root'[7.25 GB]继承

活动的'/ dev / pve / data'[14.80 GB]继承

这是RAID6上的LVM,由6个7200 rpm的Seagate Barracuda SATA驱动器制成:

CPU BOGOMIPS:53199.93

regex / second:824835

HD大小:19.69 GB(/ dev / mapper / LDatastore0-testlv)

缓冲的读取:315.17 MB /秒

平均搜寻时间:7.18毫秒

FSYNCS /秒:2439.31

这是单个Intel X25-E SATA SSD上的LVM,VG与VM所在的上述/ dev / pve / data相同:

CPU BOGOMIPS:53203.97

regex / second:825323

HD大小:7.14 GB(/ dev / mapper / pve-root)

缓冲区读取:198.52 MB /秒

平均搜寻时间:0.26毫秒

同步/秒:1867.56

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.