我所有的镜像都是在一个很大的lvm卷中，新build立的所有lvs都是用文件系统（ext3 / ext4）创build的。 所以我的承诺是，为每一台机器做到这一点：
/tmp/img_snap/ ） /tmp/convert_src/ ） /tmp/convert_dest ） /tmp/convert_src到/tmp/convert_dest 步骤1-7已经脚本化，所以在第9步我可以再次启动这个脚本。 这意味着一点点的开销，因为lv快照是没有必要的，但是我确定并意识到这一点。
由于原来的机器可以运行，直到步骤8（和步骤9应该只复制三angular洲），停机时间应该是最小的。 我也renice和ionice的rsync进程（ES），所以对其他所有系统的影响应该是最小的。 或者我以为…
INFO: task loop27:23352 blocked for more than 120 seconds ， INFO: task pdflush:7329 blocked for more than 120 seconds. ，…和他们的通话痕迹和东西。 为什么/什么时候？ 我无法弄清楚一个模式？ 有太多的IO，CPU呢？ 最重要的是：为什么不阻止我的rsync进程 – 我renice（ renice 20 -p $(pidof rsync) ）和ionized（ ionice -c2 -n7 -p$pid ）它们 – 不应该这些进程首先被阻止的那个？ rsync是一个非常好的工具。 如果使用它，请select“-aSH -delete”选项，这样就可以得到一个完全相同的目标（软链接的ctime-stamp将具有当前时间）。
从你的写作我明白，rsync所需的时间似乎是你的主要问题，而关机/启动的DomUs是相当快的（包括他们的应用程序，我假设）。
我看到你的大LV的快照中存在另一个问题，这个问题持有所有正在运行的DomU。 如果你有很多的写入请求，你的快照将会非常快速地被写入，并且快照会在写入过程中减慢DomU的速度。
在这种情况下，我会select一种不同的方法：使用软件raid 1从镜像镜像到新的LV。
如果你想要的话，你可以结合快照/ rsync来减less需要移动的数据量。 但恕我直言，时间需要得到一个整理和脚本是不值得的努力。
所以这里是计划 – 在这两种情况下，你需要块设备（环回挂载你的图像）：
A）使用md（通过mdadm设置）编写脚本到：
- closuresDomU
- 环回 – 挂载DomUs映像
- 用该图像创build一个降级的md-raid-1设备
- 用“phy：mdN”作为新的磁盘设备启动DomU
- 将raid1成员的数量从1增加到2
- 添加你的目标LV
- 更改DomU的设置，以便将来使用phy：vgX / lvY
- 如果镜像已完成，请使用新设置重新启动DomU
计划一个你有两个宕机持续一个DomU重新启动。 镜像将尽快在后台进行。
缺点：所有的数据都会被同步（RAW镜像，而不是基于文件系统）
你可以通过创buildmd-raid1（–assume clean）来解决这个问题。 但是这将是棘手的（你将需要rsync来获取你的数据到LV然后使用md-bitmap镜像增量）。
B）使用drbd（通过/etc/drbd.conf设置）如果你打算在将来切换到drbd，你应该这样做。 我没有testing这个，但看不到drbd不应该在127.0.0.1和127.0.0.2之间镜像的原因;-)
我没有testing这个，但它应该工作 – 而且比计划A更复杂。
缺点：复杂，未经testing。
但是：如果你想切换到drbd，你可以这样准备你的DomU。 以断开模式运行，直到您的集群准备就绪，然后连接，通过IP进行同步，并开始实时迁移…