Migrating VMs from Xen to Proxmox – Stuck in Initramfs

[raxa]

Hello
I'm trying to migrate VMs from two old Xen 4.4 servers to Proxmox. I've successfully extracted the disk (xvda2) images and added GRUB to make them bootable. However, when I try to boot the VMs on Proxmox, they drop me into an initramfs shell.

After some poking around, I noticed that /sys and /proc are empty, I'm guessing it because the vm use paravirtualization, but I have no clue to fix that.

the xen config file is :

#
# Configuration file for the Xen instance pc50, created
# by xen-tools 4.2 on Mon Dec 19 14:50:03 2011.
#

#
#  Kernel + memory size
#
kernel      = '/home/kernels/debian/vmlinuz-2.6.32-5-xen-amd64'
ramdisk     = '/home/kernels/debian/initrd.img-2.6.32-5-xen-amd64'

vcpus       = '1'
memory      = '2048'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'phy:/dev/vg-pc5014-bis/pc5050-disk,xvda2,w',
                  'phy:/dev/vg-pc5014/pc5050-swap,xvda1,w',
              ]


#
#  Physical volumes
#


#
#  Hostname
#
name        = 'pc5050'

#
#  Networking
#
dhcp        = 'dhcp'
vif         = [ 'mac=00:16:3E:00:00:50' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

 

[FrankList80]

I didnt make the deep dive, but migrated some x00 Linux-VMs from XCP-NG (even Suse 10x). But i utilized Clonezilla Client/Server ISO over the Network (dedicated NIC, no DHCP but fixed IP) to do this. To get your Linux-VM ready in Xenserver - you could either the WIn32 client for the change of PV/HVM or i would advise to setup a XCP-NG with XOA to make the HV/PV "Switch". Export/import from your 4.4 of course. But i never did the

I would advise: try the Clonezilla approach.

---

​

[Virtualization Support for SME and NGOs | DLI Solutions ]

 

[raxa]

I thought of copying all the file thought rsync or clonezilla, but those are old debian 6 vm doing critical work and I don't have the access to some of them.

 

[Magnus-mercer]

The issues you're encountering with "/sys" and "/proc" being empty, as well as being dropped into the initramfs shell, indicate that the system is unable to properly recognize or initialize the environment due to driver or kernel mismatches. The key to fixing this issue lies in ensuring compatibility between the Xen paravirtualized environment and Proxmox's full virtualization approach. Install "virtio" drivers, make sure disk device names and kernel parameters are correct, and adapt the bootloader configuration accordingly.

 

[c-toph]

you build a virtual hard disk and copy the data from the lvm to it.

With zfs in dom0 this works best like this:

# zfs create -V xxG vmxx-hostname

# cfdisk /dev/xen-zp01/vmxx-hostname

## Part1 100m Type *BIOS Boot* , Part2 512M Type *EFI System* Filesystem vfat, Part3 xxG Type *Linux*, Part4 xxG Type *Swap*

# apt install dosfstools

# mkfs.vfat /dev/xen-zp01/vmxx-hostname-part2

# mkfs.ext4 -L hostname-system /dev/xen-zp01/vmxx-hostname-part3

# mkfs.ext4 -L hostname-data /dev/xen-zp01/vmxx-hostname-part4

# mount /dev/xen-zp01/alt-vmxx-hostname source-mnt/

# mount /dev/xen-zp01/vmxx-hostname-part3 destination-mnt/@

# copy with mc source-mnt/destination-mnt/

Then create an img with dd and copy it to the pve. There it continues with a rescue CD and the grub installation.



Does this answer the question in the right direction?

 

[guruevi]

There are tools like https://github.com/libguestfs/virt-v2v and StarWind V2V that can convert your Xen VM, load the kernel and drivers etc into a Xen image.

The problem with Xen is that it uses a ‘special’ kernel that gets access (through a layer of software) to your physical hardware. This used to be faster when things like VFIO and hardware virtualization didn’t exist. So you’re almost-but-not-really running on hardware, while almost-but-not-really running the OS you think you’re running. From a pure software engineering perspective, Xen is much closer to Docker, if Docker were to be/run in the kernel. So like Docker, you just get a tarball with the ‘interesting’ bits of your program (in this case your OS) and the rest (device trees and boot stuff) is ‘faked’ and intercepted by the hypervisor, so any conversion solution needs to add in the missing bits for a full OS.