[SOLVED] Migrating Rocky Linux 9 from Hyper-V to Proxmox fails

ProfessionalN00b

New Member
May 21, 2025
18
4
3
Estonia
Hello

In my last thread I was struggling to get my VM export images to Proxmox and to get Windows machines in working order.
The last was achieved by injecting VirtIO drivers into the offline Windows image in WinRE.

Now I think I need to do something similar with my two Rocky Linux 9 (SELinux enabled) exports? Because the first one fails to boot right now.

VM conf:
Bash:
# qm config 102
agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 2
cpu: host
efidisk0: Storage:vm-102-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
machine: pc,viommu=virtio
memory: 2048
meta: creation-qemu=9.2.0,ctime=1748108959
name: Aquila
net0: virtio=BC:24:11:19:01:44,bridge=vmbr0,tag=2
numa: 0
ostype: l26
scsi0: Storage:vm-102-disk-1,backup=0,iothread=1,size=60G
scsihw: virtio-scsi-single
smbios1: uuid=80e228c4-5ae0-4cf8-b36d-84f16a44be95
sockets: 1
tpmstate0: Storage:vm-102-disk-2,size=4M,version=v2.0
vga: virtio
vmgenid: 04538e9f-0000-0000-0000-9f0f6251c3db

I added EFI and TPM disks because it was a Gen 2 VM in Hyper-V with UEFI and TPM enabled.

I make it this far:
1748112210278.png
I choose the first one after which a grayish screen with three dots appears. And at some point I'm in the emergency mode because the boot failed.
It advises me to run journalctl, which ends with something like this:
1748112781423.png

Is it unable to find the disk, like it was with my Windows machines?
 
RHEL-based images often build an initrd that is tailored to the machine, so changing the machine will not yield a working setup. I haven't tried with version 9, yet 6, 7 and 8 had similar problems, so I assume this is the same. Please compare to threads like this one.
 
  • Like
Reactions: Johannes S
I have see some similar problem with migration from vmware, seem than rocky don't have virtio drivers by default in initramfs when it's deployed first on different hypervistor


maybe try to boot with ide, then

sudo dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_net"

and switch to virtio-scsi again



(or you can try this command when the vm is running on hyper-v too, it'll not break anything)
 
Looks like I'm screwed.
The IDE trick worked, and the VM boots successfully now, but I blew up my WSL in my machine during troubleshooting different things and now I don't have the key to get in and NoVNC doesn't allow me to use any characters except a-z0-9-+.'
But passwords for root and my user is a 60-character random string in the password vault. NoVNC doesn't allow copying text either.
 
Pfff ... passwords ... we don't need no passwords ;)
Just boot directly into root via kernel command line init=/bin/bash and remount the disk rw. You can fix whatever you like.
 
  • Like
Reactions: Johannes S
Pfff ... passwords ... we don't need no passwords ;)
Just boot directly into root via kernel command line init=/bin/bash and remount the disk rw. You can fix whatever you like.
Yes, I considered that and it would be much easier if I could use the full keyboard in NoVNC. I can't type = nor /, for example.
 
Yes, I considered that and it would be much easier if I could use the full keyboard in NoVNC. I can't type = nor /, for example.
I feel you. So, you're not using an US layout too ... welcome to hell (with respect to this). You can send single keys to the machine via the qemu monitor. This is VERY annoying, yet it get's the job done.
 
xterm console allow copy paste, but you need to redirect output first to the serial.

(maybe copy/paste could work blindly, no sure)
Sorry, I don't know what this means. I'm not that familiar with Linux.

I feel you. So, you're not using an US layout too ... welcome to hell (with respect to this). You can send single keys to the machine via the qemu monitor. This is VERY annoying, yet it get's the job done.
Thanks for the tip, but qm sendkey doesn't help. It behaves the same way if I would type it myself. For example:
qm sendkey 102 slash types -
qm sendkey 102 shift-semicolon types Ö
 
Whatever I had on these VMs, I'm going to rebuild them as containers, which should be way easier than on Hyper-V.
Also a good idea for Linux in general if you don't need live migration. Migrating vom V2LXC is very easy and just a copy of all files (omit pseudo filesystems) and it should run directly.

Another idea would be to boot up a live linux of your choice, which should have a working network connection and then either chroot into it or running a qemu-instance via ssh -X in that live system by passing through the VM disks and fix it from there and use the windows as well as the input devices from your machine.