我之前帮朋友处理过几乎一模一样的OpenVZ到KVM的AltLinux5迁移需求，踩了好几个坑，给你分享几个亲测有效的解决步骤：

核心问题根源 #

OpenVZ是容器化环境，和VMware/KVM这类全虚拟化平台的硬件抽象逻辑完全不同——OpenVZ共享宿主机内核，没有独立的引导层和硬件驱动，直接rsync复制根目录到VM空盘，必然会因为引导缺失、硬件配置不兼容而启动失败。

分步解决流程 #

1. 先搭建可正常启动的基础VM环境 #

不要直接在空盘上rsync！先在目标VM（VMware/KVM/Hyper-V）里正常安装一遍AltLinux5，确保系统能正常启动、识别虚拟硬件。这一步是为了获取适配目标虚拟化平台的引导配置、内核和硬件驱动。

2. 用rsync同步数据（排除系统运行时目录） #

启动SystemRescueCD（或AltLinux5自带的安装光盘，更推荐后者），分别挂载原OpenVZ的根目录（可以通过网络共享，比如NFS，或者把OpenVZ的磁盘镜像挂载到救援系统）和新VM的系统盘：

• 挂载新VM系统盘到/mnt/new
• 挂载原OpenVZ根目录到/mnt/old

然后用带排除项的rsync命令同步数据，避免复制系统运行时生成的冲突文件：

rsync -aAXv \
  --exclude=/dev \
  --exclude=/proc \
  --exclude=/sys \
  --exclude=/tmp \
  --exclude=/run \
  --exclude=/mnt \
  --exclude=/media \
  --exclude=/lost+found \
  /mnt/old/ /mnt/new/

参数说明：-aAXv保证权限、属性、符号链接都同步，排除的目录都是系统启动后自动生成的，复制过去会导致冲突。

3. 修复引导与硬件配置 #

同步完成后，进入chroot环境修复系统：

# 挂载必要的系统虚拟文件系统
mount -t proc proc /mnt/new/proc
mount -t sysfs sys /mnt/new/sys
mount -o bind /dev /mnt/new/dev

# 进入新系统的根环境
chroot /mnt/new

3.1 重新生成initramfs

AltLinux5用的是mkinitrd工具，运行命令生成适配当前VM硬件的初始化镜像：

mkinitrd

3.2 修复GRUB引导

安装GRUB到新VM的磁盘（假设磁盘是/dev/sda）：

grub-install /dev/sda

然后编辑/etc/grub.conf，把原来OpenVZ里的root设备（比如/dev/ploopXXX）替换成新VM的系统分区，推荐用UUID避免设备名变化：

• 用blkid命令查看新分区的UUID，比如blkid /dev/sda1
• 把grub.conf里的root=/dev/sda1改成root=UUID=xxxxxxxxx

3.3 修正fstab

同样，编辑/etc/fstab，把所有原OpenVZ的设备路径替换成新VM分区的UUID，确保系统启动时能正确挂载磁盘。

4. 解决LiveCD挂载磁盘失败的问题 #

如果用SystemRescueCD挂载不了新VM的磁盘，大概率是老版本LiveCD不支持新虚拟化平台的磁盘控制器（比如VMware的LSI Logic、KVM的virtio）：

• 换用AltLinux5官方安装光盘启动救援模式，它自带适配自身系统的驱动，能完美识别VM的虚拟硬件
• 在VM创建时，暂时选择兼容模式的硬件：比如KVM用IDE磁盘+e1000网卡，VMware用BusLogic磁盘+e1000网卡，等系统迁移完成后再切换到高性能硬件

额外提醒：如果迁移后还是卡住，可以在VM启动时开启控制台日志（比如VMware的虚拟机控制台、KVM的virt-viewer），查看启动过程中的报错信息——大概率是某个硬件驱动缺失或者fstab配置错误，针对性修复即可。

内容的提问来源于stack exchange，提问作者shallrise