Proxmox Version 3.4-6/102d4574 .qcow2 Import Issues

M

mikecarrigan

Member
Nov 11, 2020
4
0
6
25
Hi,

I am working with an old version of Proxmox and I am having issues importing two virtual machines to Proxmox. I moved a Windows and a Debian .qcow2 file to the Proxmox server and used the mv command to replace the current hard drives of two virtual machines with the two .qcow2 files I wanted to use. Neither machine will boot to the qcow2 file, both with the error message, "Booting failed: Not a bootable disk."

For the Windows machine, GParted recognizes all the partitions associated correctly but cannot mount any of the partitions to boot.

For the Debian machine, GParted recognizes the .qcow2 file with the size of the .qcow2 file as unallocated space as opposed to the correct size.

I am not sure how to continue from here. My assumption is the SeaBIOS version (version rel-1.7.5.1-0) does not support these operating system versions. The qm set --bios command is not recognized to change to UEFI BIOS settings.

Any help would be appreciated.

Thanks
 
Hi,

To answer the obvious question, I am working on a Senior Capstone Project with a group in the Galapagos Islands. They installed this version of Proxmox VE and have not updated since. I pitched the idea but they refused for a couple reasons, mainly limited bandwidth to the islands.

I originally created the images on an XCP-ng platform and exported them to my local computer and used QEMU version 5.2.0 to convert them to .qcow2 files. I used Linux KVM to confirm that the images worked before sending them. They used WinSCP to transfer the files to the Proxmox local storage node. I was also able to remote connect to one of their computers and convert a raw image file I sent as a backup to a new .qcow2 file using the Windows version of QEMU. Both the original files and the backup files showed no corruption using the version of qemu check Proxmox VE 3 has on it.

Thank you for your response.
 
mikecarrigan said:
To answer the obvious question, I am working on a Senior Capstone Project with a group in the Galapagos Islands. They installed this version of Proxmox VE and have not updated since. I pitched the idea but they refused for a couple reasons, mainly limited bandwidth to the islands.
Click to expand...
OK, that sounds sensible, we also have installations in an antarctic research station we consulted when planning, so yeah such remote places are just different to handle.
Maybe ship a USB pen drive with a repo mirror there and use that?

mikecarrigan said:
used QEMU version 5.2.0 to convert them to .qcow2 files.
Click to expand...
That may actually a bit new and use features not available in the qcow2 code of the QEMU from PVE 5 releases.
We only shipped QEMU 5.2 recently in Proxmox VE 6.x (still not in the enterprise repo, IIRC), Proxmox VE 3.4 uses QEMU 2.1.3 and yeah also quite old Seabios and no OVMF (EFI) yet.

IMO, you have two options:

  1. Grab your self a Proxmox VE 3.4 ISO from our archive ( http://download.proxmox.com/iso/ ), set that up locally and prepare all images there, export (backup) them send them over and use that. If the should run on Proxmox VE 3.4 I'd try to avoid any external tooling, no xcp-ng, no modern QEMU/KVM from a modern Linux distro, ... those may all do things very different and be a source of failures.
  2. Do the upgrade and allow to continue to work on a more modern system providing also things like the more efficient .zstd compression (reducing data required to transfer if there are any other images to be moved over). That has two issues, I can see currently:
    1. the data transfer, I'd go for snail mail + USB pen drive or so
    2. risks of update: doing multiple big upgrades can be a feat on its own, doing those on remote locations makes errors quickly quite fatal, so more care would be required here. I'd tend to avoid upgrades at all, but rather create backups of all VMs/CTs, freshly install a new Proxmox VE 6.3 and restore the backups.
Personally I'd rather go for 3.4 now, it's just less intrusive, and see if an upgrade can be combined with a HW upgrade in some months/years and so shipped already on the HW avoiding any fatal errors and having the old HW as backup there - just an idea.
 
You must log in or register to reply here.
Top Bottom