如何在VMware上进行P2V之后使旧Linux版本启动

客户端有许多旧的Linux系统，可追溯到5到15年前，并且仍在原始硬件上运行。由于担心磁盘的使用时间等，他们希望将它们全部虚拟化到VMware vHosts上。

到目前为止，我已经能够通过VMware的Standalone Converter虚拟化几乎任何21世纪的Windows机器，并且成功率达到100％。但是，尝试在Linux机器上执行相同操作总是会导致失败，并且无法启动的VM通常会出现“内核崩溃，无法启动/ init”的错误。

我发现，如果我安装了应急CD的ISO并启动它，然后选择“从硬盘启动Linux”，系统将启动并且我可以登录，但是这使它们只能运行应急CD的内核。，例如在半径服务器上重新添加虚拟接口时，这会导致失败-尝试运行“ modprobe dummy”，该进程将轰炸：

FATAL: Could not load /lib/modules/3.14.50-std460-amd64/modules.dep: No such file or directory

在检查/ lib / modules目录时，存在的文件为：

/lib/modules/2.6.27.7-9-pae/modules.dep

哪个匹配uname -r在原始物理计算机上返回的内容：

uname -r
2.6.27.7-9-pae

在从应急CD引导的P2V VM上，它提供

uname -r
3.14.50-std460-amd64

在物理机上，init在/ sbin / init中，而根文件系统在/ dev / sda2中：

rad02:~ # which init
/sbin/init
rad02:~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              20G  3.2G   16G  17% /
udev                  243M  7.6M  236M   4% /dev
/dev/sda3              52G   15G   35G  30% /home
/dev/sdb1              74G  7.1G   63G  11% /var/log

在VM上，我尝试从硬盘启动并root=/dev/sda2 init=/sbin/init在引导加载程序时添加，并且我已经看到机器似乎试图同时启动/ init和/ sbin / init，但是仍然失败，并出现“内核崩溃，不能启动初始化”错误。

这台特定的原始计算机正在运行openSUSE 11.1 (i586)，但是我希望有一个普遍的答案，因为我想为此客户端虚拟化各种RedHat，SuSE和openSUSE系统。

我需要做什么才能使P2V虚拟机启动并成功启动？

编辑：好的，感谢那些发表评论的人，我现在可以更好地理解问题了-Grub可以看到磁盘正常，但是实际的内核系统不能，而且很可能是由于/ etc / sysconfig /中缺少控制器驱动程序内核文件的initrd_modules行。

这是原始物理主机上的内容：

INITRD_MODULES="processor thermal ata_piix ata_generic piix ide_pci_generic fan jbd ext3 edd"

这是P2V转换已放入VM的文件中的内容：

INITRD_MODULES="mptscsih mptspi mptsas scsi_transport_spi scsi_transport_sas BusLogic ahci pcnet32 processor thermal ata_piix ata_generic piix ide_pci_generic fan jbd ext3"

在下载了openSUSE 11.1安装DVD并运行了“修复已安装的系统”选项之后，该选项已更改为：

INITRD_MODULES="ahci mptsas ata_piix ata_generic piix ide_pci_generic jbd ext3"

从较早的应急CD引导时，我在列出的所有模块上找到了一个位置，并且所有东西都存在ide_pci_generic驱动程序-鉴于VMware将SATA Lsi Logic作为标准磁盘类型，我假设它将使用IDE驱动程序？

我还有另一台运行openSUSE 10的P2V虚拟机，该虚拟机最初与拒绝启动存在相同的问题，但是在关闭电源数月后，却意外地正确启动了（并且已经多次重新启动，总是成功完成）， / etc / sysconfig / kernel在那我得到：

INITRD_MODULES="mptscsih mptspi scsi_transport_spi BusLogic pcnet32 piix ata_piix processor thermal fan jbd ext3"

那我从这里去哪里呢？

编辑2：

下面的AB所打勾的答案解决了此问题。

按照给出的说明，并使用一个备用虚拟机，该虚拟机已使用与我们尝试p2v的计算机相同的Linux版本重新安装，我在/ tmp，物理，虚拟和组合下创建了三个目录。按照指示从物理机中提取initrd和System.map文件，然后将其解压缩到/ tmp / physical下，然后从我所在的VM（即同一操作系统的工作VM）中提取相同的文件并解压缩/ tmp / virtual中的那些。

出于好奇，我对每个目录的du输出进行了比较，因此：

cd /tmp/physical
du > /tmp/ph.txt
cd /tmp/virtual
du > /tmp/vi.txt
cd /tmp
cat ph.txt |cut -d'.' -f2,3,4,5,6 |sort > ph-sorted.txt 
cat vi.txt |cut -d'.' -f2,3,4,5,6 |sort > vi-sorted.txt
diff ph-sorted.txt vi-sorted.txt

产生此输出的内容-差异很小，但有几个文件：

21,22d20
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/hid
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/hid/usbhid
26c24,25
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/input
---
> /lib/modules/2.6.27.7-9-pae/kernel/drivers/message
> /lib/modules/2.6.27.7-9-pae/kernel/drivers/message/fusion
29,31d27
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/usb
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/usb/core
< /lib/modules/2.6.27.7-9-pae/kernel/drivers/usb/host

然后，我将/ tmp / physical和/ tmp / virtual的完整内容复制到了/ tmp / combo中（其中虚拟的是第二个，因此会覆盖所有冲突）。

然后我做了（按照下面的回答指示）

depmod -b /tmp/combo -F /tmp/combo/System.map-2.6.27.7-9-pae -v 2.6.27.7-9-pae

它抛出了依赖性错误的屏幕，但否则运行正常，随后

cd /tmp/combo
find . -print0 | cpio -o -0 -H newc |gzip -9 > /tmp/initrd-2.6.27.7-9-pae

我从应急CD上启动了失败的p2v，然后将其放到网络上，复制 initrd-2.6.27.7-9-pae到/ boot上，分离了应急CD ISO并重新引导-它可以正常工作！openSUSE 11.1在p2v VM上愉快地运行，并且服务似乎正常工作-成功！

— 烈焰
source

磁盘控制器硬件呢？如果物理引导程序的initramfs（或非常旧的真实ramdisk映像）仅包含特定硬件控制器的驱动程序，而没有vmware支持的通用scsi控制器，并且vmware不会修改该引导程序以解决该问题，那么您最终将没有磁盘检测。我在带有一些RAID控制器的HP服务器上遇到了这个问题（是cciss吗？），而suse系统在引导中仅安装了尽可能少的内核驱动程序集。我必须使用cpio“打开” initramfs，从系统中复制丢失的驱动程序，然后将initramfs放回虚拟机中

— AB

您可以尝试启动修复。下载32位ISO并将其作为虚拟CD引导到VM中。您也可以chroot从应急CD中进行试验。根据您发现的内容，可能可以在不使用应急CD的情况下修补VM以使其启动。

— AFH

同样（可能还有第一个），请确保仅使用单个CPU，然后尝试将虚拟化引擎更改为显式值之一。

— AFH

为此，我尝试了引导修复磁盘，但似乎失败了，因为它找不到openSUSE 11.1版本的Grub的存储库-它要求我复制和粘贴的命令（涉及zypper）失败。@AB我认为驱动程序是正常的，因为当尝试正常启动openSUSE启动屏幕时，可以在标准和故障保险之间进行选择。OK-只有在此之后，它才应该启动init，所有事情都会出轨。

— Pyromancer

引导菜单正在使用grub，并且可以读取磁盘。因此它可以读取initramfs（出于历史原因仍称为initrd），并将其沿着内核放入ram中。内核将从RAM文件系统运行伪造的init。这个虚假的init将运行一些脚本（cryptfs lvm等），但是将找不到任何磁盘。因此，脚本永远无法执行实际的/ sbin / init：一切都出轨了

— -AB的

我碰巧遇到了一个类似的问题（缺少驱动程序，但这里可能更多是由于从IDE / ATA到SCSI的更改引起的），所以是从内存中引起的：

检索/boot/initrd.img-2.6.27.7-9-pae文件（从物理服务器或从VM使用应急磁盘）以及/boot/System.map-2.6.27.7-9-pae
使用gzip，cpio和depmod命令（以及fakeroot或root访问权限）将它们放在任何Linux计算机上的/ tmp中

成为root或使用fakeroot模拟它（稍后用于cpio）

$ fakeroot
# mkdir /tmp/cpio
# cd /tmp/cpio
# gunzip < /tmp/initrd.img-2.6.27.7-9-pae | cpio -i -m

棘手的部分：找出中可能缺少的驱动程序/tmp/cpio/lib/modules/2.6.27.7-9-pae/。您似乎有一个候选人名单。预见（并尝试并纠正）的一些问题：看来您的物理服务器正在使用ATA / IDE而不是SCSI。如果从ATA转到SCSI，驱动器将从/ dev / hda / dev / hdb ...更改为/ dev / sda / dev / sdb ...，您将再次遇到引导问题（仍找不到磁盘）。我想那就是你得到的。
- 要么更改仿真硬件以使其与先前的硬件匹配，要么使用IDE / ATA，而不要使用SCSI（Buslogic）。我会的也许Suse 11救援DVD就足够了。
- 或准备进行编辑（在与应急CD一起启动的VM中，也可能在其他地方的initrd中！）/ etc / fstab，通过将/ dev / hdX更改为/ dev / sdX来解决所有这些问题。由于您的安装较旧，因此我不会依靠现代的UUID =设置来解决此问题。除非我知道在fstab旁边每个地方都要编辑，否则我将避免这种解决方案
如果缺少某些驱动程序，则说明该驱动程序确实丢失或是内置的（请参阅后面的depmod）。从物理服务器复制，或者从通过应急CD引导的VM进行复制，甚至从某些Suse存储库（如果您确定它的版本完全相同）中复制必须添加的模块/tmp/cpio/lib/modules/2.6.27.7-9-pae/。请注意，某些模块具有依赖性，无疑会超出所需的数量（只要VM的/ boot中有空间...）
然后重新构建模块依赖关系列表
```
# depmod -b /tmp/cpio -F /tmp/System.map-2.6.27.7-9-pae -v 2.6.27.7-9-pae
```
您可以检查/tmp/cpio/lib/modules/2.6.27.7-9-pae/modules.builtin丢失的模块是否确实存在（直接在内核中）

重新打包树（并覆盖先前的initrd文件）

# cd /tmp/cpio
# find . -print0 | cpio -o -0 -H newc |gzip -9 > /tmp/initrd.img-2.6.27.7-9-pae

将此文件放回VM上的/ boot中。VM现在应该正确启动

— AB
source

延迟响应的歉意已经过去了几天。感谢您的全面答复，我将在今天晚些时候尝试实现此目标并报告结果。

— Pyromancer

物理服务器是SCSI，它是Dell PowerEdge SC1425，驱动器分区被标识为/ dev / sdaX。为了实现上述说明，我使用了一个故障的P2V分区之一，并安装了openSUSE 11.1引导盘，并进行了全新安装，但使用了故障p2v中物理机的磁盘布局和处理器设置。此版本已正确安装，并且启动非常愉快，因此此版本的openSUSE能够在此vHost上的VM中正常运行。我在2个目录中完成了上述操作，一个目录用于物理文件，一个目录用于虚拟文件，现在将尝试将它们合并。

— Pyromancer