42 lines
2.8 KiB
Markdown
42 lines
2.8 KiB
Markdown
**Purpose**:
|
|
When you migrate virtual machines from Hyper-V (and possibly other platforms) to ProxmoxVE, you may run into several issues, from the disk formats being in `.raw` format instead of `.qcow2`, among other things. One thing in particular, which is the reason for this document, is that if you migrate Rocky Linux from Hyper-V into ProxmoxVE using Veeam Backup & Replication, it will break the storage system so badly that the operating system will not boot.
|
|
|
|
|
|
### Fixing Boot Issues
|
|
Some high-level things to do to fix this are listed below:
|
|
- Switch the VM processor type to `host`.
|
|
- The socket and core counts are reversed, so a single socket CPU with 16 cores will appear like 16 sockets with one core each, flip these around to correct this issue.
|
|
- The storage controller needs to be set to `VirtIO iSCSI`
|
|
- The display driver needs set to `Default`
|
|
|
|
#### Dracut Emergency Shell
|
|
If you start the VM and you reach a "dracut" prompt, then the bootloader got nuked and needs to be regenerated. Follow the steps below to work through this process:
|
|
- Boot from a Rocky Linux 9.5+ installation ISO in the broken Rocky Linux VM
|
|
- Select "**Troubleshooting -->**" in the boot menu
|
|
- Select "**Rescue a Rocky Linux System**"
|
|
- Press through the prompt with value `1` and `Continue` to select the automatic mounting of the detected operating system of the virtual machine
|
|
- Press **<ENTER>** to enter the shell, then run the following commands to fix the booting issues
|
|
```sh
|
|
chroot /mnt/sysroot
|
|
dracut --force --regenerate-all
|
|
grub2-mkconfig -o /boot/grub2/grub.cfg
|
|
exit
|
|
exit
|
|
```
|
|
!!! info "Boot Fix May Trigger Reboot Twice"
|
|
During the process, you may notice that the VM reboots itself a second-time. This is normal and can be left alone. The VM will eventually reach the login screen. Once you get this far, you can login and fix the networking issues in the VM to get it stabilized.
|
|
|
|
### Fixing Network Issues
|
|
The VM will lose the adapter name of `eth0` and put something else like `ens18` that needs to be reconfigured manually to get networking functional again:
|
|
- Type `ethtool ens18`, and if the link speed is `Unknown!`, then poweroff the VM and switch the network adapter from `VirtIO (paravirtualized)` to `Intel E1000`, then boot the VM back up.
|
|
- Run the following commands to assign the new `ens18` interface as a networking interface for the VM to use:
|
|
```sh
|
|
# Create the Interface (Replace the IP & DNS Variables)
|
|
nmcli connection add type ethernet ifname ens18 con-name ens18 ipv4.method manual ipv4.addresses 192.168.3.21/24 ipv4.gateway 192.168.3.1 ipv4.dns "1.1.1.1 1.0.0.1"
|
|
|
|
# Bring the Connection Online
|
|
nmcli connection up ens18
|
|
```
|
|
|
|
!!! success "VM Successfully Fixed"
|
|
At this point, the virtual machine should be booting, and have network access, bringing it back into production use. |