Um cliente tem vários sistemas Linux antigos, datados entre cinco e quinze anos atrás, ainda sendo executados no hardware original. Devido a preocupações com a idade dos discos, etc., eles gostariam de tê-los todos virtualizados no VMware vHosts.
Eu consegui virtualizar máquinas Windows de praticamente qualquer era do século 21 por meio do Standalone Converter da VMware, até agora com uma taxa de sucesso de 100%. No entanto, tentar fazer o mesmo com as máquinas Linux invariavelmente resulta em falha, e uma VM que não inicializa, geralmente dando um erro ao longo das linhas de "kernel panic, não é possível iniciar / init".
Descobri que se eu montar o ISO de um CD de resgate e inicializar isso, e depois escolher "inicializar o Linux do disco rígido", os sistemas serão inicializados e eu posso fazer o login, o que os deixa executando o resgate O kernel do CD ao invés do on-board, que então leva a falhas ao tentar, por exemplo, adicionar novamente as interfaces dummy em um servidor radius - tentando rodar o "modprobe dummy" com as bombas de processo:
FATAL: Could not load /lib/modules/3.14.50-std460-amd64/modules.dep: No such file or directory
No exame do diretório / lib / modules, o arquivo que está presente é:
/lib/modules/2.6.27.7-9-pae/modules.dep
Que corresponde ao que uname -r retorna na máquina física original:
uname -r
2.6.27.7-9-pae
Na VM P2V inicializada a partir do CD de recuperação, ela é fornecida
uname -r
3.14.50-std460-amd64
Na máquina física, o init está em / sbin / init e o sistema de arquivos raiz é / 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
Na VM, tentei inicializar o disco rígido e adicionar root=/dev/sda2 init=/sbin/init no momento do boot load, e vi a máquina tentar iniciar ambos os / init e / sbin / init - mas ainda falha com um erro "kernel panic, cannot start".
Esta máquina original em particular está rodando openSUSE 11.1 (i586) , mas eu estou esperando uma resposta geral, pois há uma variedade de sistemas RedHat, SuSE e openSUSE que eu gostaria de virtualizar para este cliente.
O que preciso fazer para que as VMs com P2V iniciem o init e inicializem com êxito?
Edit: Ok, obrigado por aqueles que comentaram Eu agora entendo melhor o problema - O Grub pode ver os discos bem, mas o sistema de kernel não pode, e este é provavelmente um driver de controlador ausente no / etc Linha initrd_modules do arquivo / sysconfig / kernel.
Veja o que está no host físico original:
INITRD_MODULES="processor thermal ata_piix ata_generic piix ide_pci_generic fan jbd ext3 edd"
Veja o que a conversão de P2V colocou no arquivo da 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"
E depois de baixar um DVD de instalação do openSUSE 11.1 e executar a opção "reparar o sistema instalado", isso foi alterado para:
INITRD_MODULES="ahci mptsas ata_piix ata_generic piix ide_pci_generic jbd ext3"
Enquanto inicializado a partir do CD de resgate anterior eu fiz uma localização em todos os módulos listados e tudo barra o driver ide_pci_generic estavam presentes - dado que o VMware dá Lógica SATA Lsi como o tipo de disco padrão Eu assumo que ele estaria usando um IDE motorista?
Eu tenho outra VM com P2V rodando o openSUSE 10 que inicialmente teve o mesmo problema de se recusar a inicializar, mas depois de ter sido desligado por vários meses, surpreendentemente inicializou corretamente (e foi reiniciado várias vezes, sempre com sucesso) , olhando em / etc / sysconfig / kernel em que eu recebo:
INITRD_MODULES="mptscsih mptspi scsi_transport_spi BusLogic pcnet32 piix ata_piix processor thermal fan jbd ext3"
Então, para onde vou daqui?
Editar 2:
A resposta assinalada de A.B abaixo resolveu este problema.
Seguindo as instruções fornecidas e usando uma VM sobressalente que foi instalada recentemente usando a mesma versão do Linux que a máquina que estávamos tentando p2v, criei três diretórios em / tmp, físico, virtual e combinado. Seguindo as instruções, obtive os arquivos initrd e System.map da máquina física e os descompactei sob / tmp / physical, depois puxei os mesmos arquivos da VM em que estava (ou seja, uma VM funcional do mesmo sistema operacional) e descompactei aqueles em / tmp / virtual.
Por curiosidade eu fiz um diff na saída de du para cada diretório, assim:
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
Que produziu essa saída - pouca diferença, mas alguns arquivos:
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
Eu então copiei o conteúdo completo de ambos / tmp / physical e / tmp / virtual para / tmp / combo (com o virtual vindo em segundo lugar, portanto, sobrescreverei quaisquer conflitos).
Eu então fiz (conforme as instruções na resposta abaixo)
depmod -b /tmp/combo -F /tmp/combo/System.map-2.6.27.7-9-pae -v 2.6.27.7-9-pae
que jogou fora as telas de erros de dependência, mas correu OK, seguido por
cd /tmp/combo
find . -print0 | cpio -o -0 -H newc |gzip -9 > /tmp/initrd-2.6.27.7-9-pae
Eu inicializei o p2v com falha do CD de resgate e coloquei na rede, copiei initrd-2.6.27.7-9-pae para / boot nele, desativei o ISO do CD de resgate e reiniciei - e funcionou! openSUSE 11.1 rodando alegremente na VM p2v, e os serviços parecem funcionar normalmente - sucesso!