☰

使用 lvm 而不是 libvirt 创建卷的缺点是什么？存储池存在

tag-icon • tag-icon lvm libvirt
使用 lvm 而不是 libvirt 创建卷的缺点是什么？存储池存在

在服务器 A 上创建虚拟机时，virt-install 在 libvirt 存储池“POOL”中创建了一个 libvirt 卷“VM”。

 virsh-install --disk pool=POOL,size=$HDDSIZE,$DISKOPT -n VM

正如预期的那样，libvirt 显示例如

# virsh vol-list POOL

Name                 Path
-----------------------------------------
VM                  /dev/VOLUMEGROUP/VM
anotherVM           /dev/VOLUMEGROUP/anotherVM

将虚拟机迁移到不与服务器 A 共享存储的服务器 B 时，我改为使用 lvm 创建逻辑卷：

 lvcreate -l $EXTNSIZE -n lvmVM VOLUMEGROUP

作为不是预期（但可以说是预期的），服务器 B 上的 libvirt 确实不是识别 lvmVM。

# virsh vol-list POOL

Name                 Path
-----------------------------------------
someOtherVM         /dev/VOLUMEGROUP/someOtherVM

无论如何，我都能手动启动虚拟机。很好。但是...

  • 让 libvirt 对 POOL 中的新卷保持盲目状态是否存在危险/缺点？
  • 例如，libvirt 是否会在重启时无法自动重启 VM 等等？

（或者，从另一个角度来看：在通过 virt-inst 等进行初始创建之后，使用 libvirt 卷而不是仅使用存储池内的 lvm 卷有什么好处？）

  • 有没有办法让 libvirt 识别该卷？
  • ...但是这个识别/转换过程会将元数据写入 lvmVM 并从而损坏 VM 虚拟磁盘吗？

细节：

  • 在两台服务器上，lvm 组“VOLUMEGROUP”用于 libvirt 存储池“POOL”。
  • 在两台服务器上，lvm 均显示预期的卷。只是 libvirt 卷“层”不同。
  • Debian Linux 8 x86_64，lvm2 2.02.111-2.2+deb8u1，libvirt 1.2.9-9+deb8u3
  • 大小为 40 GB，DISKOPT='bus=virtio,cache=writethrough,io=threads,sparse=false'
  • libvirt 之下使用 KVM 和 qemu。

  • 虚拟机“VM”的 libvirt xml 具有：

    disk type='block' device='disk' 
 driver name='qemu' type='raw'
 source dev='/dev/VOLUMEGROUP/VM'
 target dev='vda' bus='virtio'

相关内容