物理服务器迁移至虚拟机
2009年7月23日 23:03
这几天一直在做一件事，要把众多的物理服务器，迁移至虚拟机中。这样做的目的是用来备份当前系统，当物理服务器的系统发生故障时，可以使用虚拟机中的备份系统，快速的恢复应用。而且，也可以为以后服务器的完全虚拟化做些铺垫。
闲话少叙，来讲讲我几天实践的经验 :)
实验前提：
物理服务器：OS: RedFlag 2.4.21-9.30AXsmp i686
＃cat /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext2 defaults 1 2 LABEL=/opt /opt ext3 defaults 1 2 /dev/sda3 swap swap defaults 0 0
# df -h /dev/sda2 14G 2.5G 11G 19% / /dev/sda1 99M 13M 82M 14% /boot /dev/sda5 252G 774M 238G 1% /opt
虚拟机：VMware GSX Server for linux 3.0
宿主OS：CentOS （系统无关紧要）
所用工具：sysrescuecd，同版本RedFlag的恢复光盘
一，备份物理服务器中的分区
话说备份有很多种方式，我只是粗浅知道个大概，就不举例了，等有机会再说。
这里我使用的工具是fsarchiver（需翻墙）。之所以用它，是因为：
1，它备份的是分区上实际使用的文件，而并不是整个分区。而且备份时可以选择压缩级别，大大节省了迁移后在虚拟机中使用的磁盘空间。
2，可以识别众多文件系统。（与上面的理由冲突么？）
3，可对备份恢复内容进行校验。
4，命令简单 :)
5，还原时可改变原物理服务器中的文件系统，例如ext3-->reiserfs。
6，可把多个文件系统备份到一个文件中去。哇哦
此工具包含在sysrescuecd中。用sysrescuecd启动物理服务器自不必多说，要注意的是，在备份过程中，备份的内容是不应该发生改变的！因此，对要备份的分区应该umount，或者mount read-only。
fsarchiver其实可以对mount的分区进行备份，但官方并不推荐，应该是还不稳定。如果真能实现，那就太cool了。
挂载/opt分区，此次实验中不备份/opt分区，用它只是来存储备份文件。 # mount /dev/sda5 /mnt/backup 备份分区 # fsarchiver savefs /mnt/backup/redflag-bootfs-ext2.fsa /dev/sda1 # fsarchiver savefs /mnt/backup/redflag-rootfs-ext3.fsa /dev/sda2
二，传送备份的文件到VMware Server上去
就是用scp。可惜fsarchiver不能把备份文件直接保存在NFS分区上，提示有错误（或者是我没搞对？）。不知道还有没有更简便的方法？
# scp /mnt/backup/redflag-bootfs-ext2.fsa user@host:/opt/fsarchiver/ # scp /mnt/backup/redflag-rootfs-ext3.fsa user@host:/opt/fsarchiver/
三，获取虚拟磁盘大小
之前说过，在VMware Server上我们要尽量节省空间，这样才放的下更多的物理系统。因此，我们先看看原来的物理服务器中，实际使用的磁盘空间是多少：
# fsarchiver archinfo ./redflag-bootfs-ext2.fsa # fsarchiver archinfo ./redflag-rootfs-ext3.fsa
/boot 使用了十几M，/root 使用了3G多空间。知道这些后，我们就可以着手在虚拟机中规划分区，并进行恢复了。
给虚拟机划分一块5G的硬盘，进行分区 #fdisk －l /dev/sda /dev/sda1 /boot 50M /dev/sda2 swap 500M /dev/sda3 / 4G
四，在虚拟机中进行恢复
用sysrescuecd启动虚拟机，进行恢复。
恢复/boot分区，文件系统为ext2 # fsarchiver restfs redflag-bootfs-ext2.fsa id=0,dest=/dev/sda1,mkfs=ext2 恢复/分区，文件系统为ext3 # fsarchiver restfs redflag-rootfs-ext3.fsa id=0,dest=/dev/sda3,mkfs=ext3
需要重新安装grub。
当在sysrescuecd中chroot进入系统后，使用应用程序总会发生段错误，应该是和kernel与gcc的版本有关吧。无奈之下，只好使用了同版本的RedFlag恢复光盘，重新启动系统。不过这也带来一个好处，后面会说。
进入虚拟机中的系统 # chroot /dev/sda3 /bin/bash 重新安装grub # grub >>> root (hd0,0) >>> setup (hd0) >>> quit 此时，grub已经重新装在了这块硬盘的MBR上。
修改/etc/fstab，以适应新系统的需要。
兴奋的重启虚拟机，grub正常启动 :) 可在加载内核时，出现了“kernel panic”的错误，显示找不到根分区。肯定是磁盘控制器的驱动没有加载上，该动动initrd了。
五，修改initrd.img文件
此文件的来历及发展也很有趣，在内核2.4与内核2.6版本中的处理方法也不相同，留到以后有空再聊。现在的目标是让系统中的initrd文件尽快的能用起来。
我们现在正在RedFlag的恢复光盘中，它为什么可以正常启动系统？显然，它在启动时加载了必须的驱动。我们此时只需要寻找到磁盘控制器的驱动即可。BusLogic: SCSI storage controller。就是他！
查看原来initrd.img的内容 # cp /mnt/sda3/boot/initrd.img /mnt/sda3/tmp/initrd.gz # cd /mnt/sda3/tmp 解压 # gunzip initrd.gz 挂载 # mount -o loop initrd /mnt/sda3/tmp/init 现在就可以看到initrd.img的内容了 # ls /mnt/sda3/tmp/init bin/ dev/ etc/ lib/ linuxrc* loopfs/ proc/ sbin sysroot/
现在，只需要把驱动拷贝到lib/目录中，并修改linuxrc文件，通知内核加载此驱动即可。
# cp /lib/modules/`uname -r`/kernel/drivers/scsi/BusLogic.o /tmp/init/lib
# vi /tmp/init/lib/linuxrc
＃增加必须的模块，去除不需要的模块
insmod /lib/BusLogic.o
好了，重新生成initrd.img
卸载initrd # umount /tmp/init 压缩 # gzip initrd 覆盖 # cp initrd.gz /boot/initrd.img
OK，重启……
问题解决，在启动过程中，RedFlag会启动一个检测程序，检查硬件的变化，并自动配置。
至此，迁移过程结束，物理服务器中的系统已经在虚拟机中跑的欢畅
遗留的问题：
1，自动化处理。只有达到自动化，才有大量迁移的可能。
2，网段，光纤存储等问题。
3，资源分配问题。
这次迁移只是一次实验操作，东拼西凑，其中很多地方做得不漂亮，可改进的地方还有很多。但思路应该大致就是这样，您有什么好办法，也说来听听