Import a QCOW2 Into Proxmox

JaredBusch

@FATeknollogee said in Import a QCOW2 Into Proxmox:

I followed this instruction: https://serverfault.com/questions/843212/existing-kvm-vm-to-proxmox-ve

That no longer works because they no longer use qcow2 by default

FATeknollogee

@JaredBusch Since when?

JaredBusch

@FATeknollogee said in Import a QCOW2 Into Proxmox:

@JaredBusch Since when?

I have no clue. I have not used Proxmox until I started testing last week.

The thing you linked is very old. I don't know when things changed. But with the current default use of lvm-thin and block data, or wtfever they call it, and not qcow2 files, you cannot just copy things in.

You have to import it as @scottalanmiller noted above.

JaredBusch

https://forum.proxmox.com/threads/uploading-qcow2-file-to-proxmox.75008/#post-334363

VoIP_n00b

My installation is using qcow2

JaredBusch

@VoIP_n00b said in Import a QCOW2 Into Proxmox:

My installation is using qcow2

Yes Aaron, we know that you are a bit slow on the uptake. You don't need to make it easy for us.

JaredBusch

@scottalanmiller said in Import a QCOW2 Into Proxmox:

This works for many formats other than qcow2 as well. A straight block image in ISO / img format will work just fine, too.

Yes it does.

root@pm01:~# qm importdisk 100 tophat/Manual_DD_Unzipped/live_sda.img local-zfs 
importing disk 'tophat/Manual_DD_Unzipped/live_sda.img' to VM 100 ...
transferred: 0 bytes remaining: 73274490880 bytes total: 73274490880 bytes progression: 0.00 %
>snippy snip<
transferred: 72666312605 bytes remaining: 608178275 bytes total: 73274490880 bytes progression: 99.17 %
transferred: 73274490880 bytes remaining: 0 bytes total: 73274490880 bytes progression: 100.00 %
transferred: 73274490880 bytes remaining: 0 bytes total: 73274490880 bytes progression: 100.00 %
Successfully imported disk as 'unused0:local-zfs:vm-100-disk-0'
root@pm01:~#

CCWTech

root@spwj-phy:/mnt/usbdest# qm importdisk 100 vm-100-Apps.qcow2 local-lvm
importing disk 'vm-100-Apps.qcow2' to VM 100 ...
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
Logical volume "vm-100-disk-0" created.
WARNING: Sum of all thin volume sizes (1.95 TiB) exceeds the size of thin pool pve/data and the size of whole volume group (1.63 TiB).
transferred: 0 bytes remaining: 2147483648000 bytes total: 2147483648000 bytes progression: 0.00 %

Googling what to do now...

CCWTech

It looks like it's easy to change: https://www.thegeekdiary.com/how-to-enable-the-automatic-extension-for-a-thin-lvm-volume/

But, if it auto extends, what tells it that there is a hard limit? The side of the drive you set up when making the VM?

It can't auto extend to infinity.

CCWTech

Ok, it looks like I just need to import it and adjust it in Windows and then in proxmox when I am done.

CCWTech

A couple of things I ran into. You need to make sure that you switch to BIOS to UEFI or it won't recognize that there is anything to boot to.

And you have to choose something other than VIRTIO for the controller. Because it's likely that there aren't VIRTIO drivers installed you have to use something else.

You can't install drivers to a device you don't have so...

You can add a 2nd hard drive to the mix as VIRTIO to get Windows to ask for drivers, then you can shut down, trash the 2nd HD and make your main disk use the VIRTIO controller. Obviously use the VIRTIO drivers for the other unknown devices that pop up and you are good to go.

JaredBusch

@ccwtech said in Import a QCOW2 Into Proxmox:

A couple of things I ran into. You need to make sure that you switch to BIOS to UEFI or it won't recognize that there is anything to boot to.

And you have to choose something other than VIRTIO for the controller. Because it's likely that there aren't VIRTIO drivers installed you have to use something else.

You can't install drivers to a device you don't have so...

You can add a 2nd hard drive to the mix as VIRTIO to get Windows to ask for drivers, then you can shut down, trash the 2nd HD and make your main disk use the VIRTIO controller. Obviously use the VIRTIO drivers for the other unknown devices that pop up and you are good to go.

None of that has anything to do with the actual import of a QCOW2 into ProxMox.

This is all crappy windows design. I've imported many things and with the exception of an ancient RHEL 4 system, had zero issues importing something that was already a QCOW2.

unquietwiki

For anyone curious, I was trying to migrate a Windows VM from QNAP to Proxmox, and this came in handy. Notes...

The VM type can be set to Q35/UEFI.
There may be multiple disk images on the QNAP box for the same VM: you need all of them in the same directory for the QCOW tooling to work correctly. Turn off the VM in Virtualization Manager, and copy them over to Proxmox via SSH; you can also download them via File Manager first.
importdisk on the latest file; it'll rebuild a RAW file where Proxmox keeps the data.
Mount the file in Proxmox as an IDE drive, and don't forget to set the boot order ahead of CD-ROM & Network.
https://github.com/virtio-win/virtio-win-pkg-scripts has the latest guest drivers for QEMU/KVM. https://superuser.com/questions/1057959/windows-10-in-kvm-change-boot-disk-to-virtio has some strategies for migrating from IDE to VirtIO; again, don't forget to check the boot order when detaching/re-attaching the disk image. Adding a tiny VirtIO drive while the system was up, shutting down, detaching the two drives & attaching the main as VirtIO; was the working solution for me.

Side note: unless you remember to look up your virtual MAC address in the QNAP VM, you'll need to reconfigure your network adapter after migration.

JaredBusch

@scottalanmiller said in Import a QCOW2 Into Proxmox:

Edit: As Jared linked below in the discussion, this process requires that the block image file (qcow, iso, etc.) but on local storage and not being pulled over a network.

I would like to note, that "local" only means you cannot directly pull it across a network.

Using anything properly mounted works just fine. Because that is "local" as far as any commands are concerned.

I am currently migrating my home stuff from an old desktop running raw KVM on Fedora to an old HP Microserver running Proxmox 7.

I mounted the old KVM drives:

mkdir /migration_a
mkdir /migration_b
mount -t nfs 10.254.103.5:/var/lib/libvirt/images/raid_a /migration_a/
mount -t nfs 10.254.103.5:/var/lib/libvirt/images/raid_b /migration_b/

Then ran the imports.

qm importdisk 101 /migration_a/plex.qcow2 zfs-pool1 # 30GB took 9 minutes
qm importdisk 102 /migration_b/nas_boot.qcow2 zfs-pool1 # 20GB took 6 minutes
qm importdisk 102 /migration_b/nas_data.qcow2 zfs-pool1 # 2TB, guessing 12 hours

scottalanmiller

@jaredbusch good point, Linux doesn't "detect non-local" like Windows does.

Dashrender

@scottalanmiller said in Import a QCOW2 Into Proxmox:

@jaredbusch good point, Linux doesn't "detect non-local" like Windows does.

ug.. what a pain that is!

JaredBusch

@dashrender said in Import a QCOW2 Into Proxmox:

@scottalanmiller said in Import a QCOW2 Into Proxmox:

@jaredbusch good point, Linux doesn't "detect non-local" like Windows does.

ug.. what a pain that is!

ummm wut?

Dashrender

@jaredbusch said in Import a QCOW2 Into Proxmox:

@dashrender said in Import a QCOW2 Into Proxmox:

@scottalanmiller said in Import a QCOW2 Into Proxmox:

@jaredbusch good point, Linux doesn't "detect non-local" like Windows does.

ug.. what a pain that is!

ummm wut?

that windows detects SMB shares as remote.