bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update Workflows/Veeam Backup & Replication/Migrating VMs to ProxmoxVE.md

Browse Source
This commit is contained in:
Nicole Rappe
2025-04-20 23:39:14 -06:00
parent f7559f9d1c
commit 0d23a348e8
1 changed files with 29 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
Workflows/Veeam Backup & Replication/Migrating VMs to ProxmoxVE.md
View File

@ -1,28 +1,21 @@
**Purpose**:
When you migrate virtual machines from Hyper-V to ProxmoxVE, you may run into several issues, from the disk formats being in `.raw` format instead of `.qcow2`, among other things.
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.
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.
Some high-level things to do to fix this are listed below, as well as commands to fix the booting issues when you get that far.
- Switch the processor type to `host`
- Fix the socket and cores are reversed, so a single socket CPU with 16 cores will appear like 16 sockets with one core each
- 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
- The storage controller needs to be switched to `VirtIO iSCSI`
- The VM may need you to switch the network adapter from `VirtIO` to `E1000` if you run `ethtool ens18` and find it's not detecting the link speed with `Unknown!`, and everything else is missing.
- Run the following commands to assign the new `ens18` interface as a networking interface for the VM to use:
```sh
nmcli connection add type ethernet ifname ens18 con-name ens18 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.3.1 ipv4.dns "1.1.1.1 1.0.0.1"
nmcli connection up ens18
```
- The display driver needs switched to `Default`
- The operating system needs to have the bootloader and storage drivers regenerated, see the instructions below:
- 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` 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
### 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
@ -30,8 +23,20 @@ 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.
After this is done, you can turn off / sudo poweroff the VM and allow the VM to reboot.
### 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"
!!! info "May 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 all of the *other* issues in the VM to get it stabilized.
# 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.