Skip to content

Migrating VMs to ProxmoxVE

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 to enter the shell, then run the following commands to fix the booting issues 
    chroot /mnt/sysroot
dracut --force --regenerate-all
grub2-mkconfig -o /boot/grub2/grub.cfg
exit
exit

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: 
    # 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

VM Successfully Fixed

At this point, the virtual machine should be booting, and have network access, bringing it back into production use.

Convert VM Disk from .RAW to .QCOW2

Given that the migration process via Veeam Backup & Replication ignores the destination disk format (at the time of writing this), it is necessary to convert the format of the disk from .raw to .qcow2 so that you can perform things like VM snapshots, which are essential during updates, development, and testing.

Open a shell onto the ProxmoxVE server that is currently holding the VM that you need to convert the disks for, then locate the disks (this is not explained here, yet), and run the following commands to convert them.

# Convert a Single Disk
qemu-img convert -f raw -O qcow2 source.raw destination.qcow2

# Convert All Disks in a Given Directory
find . -type f -name "*.raw" -exec sh -c 'qemu-img convert -f raw -O qcow2 "$1" "${1%.raw}.qcow2"' _ {} \;