Import a QCOW2 Into Proxmox
-
If you already have a QCOW2 file, either coming from another KVM system or converted from another format, to use it in Proxmox you need to import it because you cannot copy the files directly into the storage location.
To do this, you need to either copy the qcow2 file to the local file system or you can mount it remotely on NFS or an SSH filesystem or similar so that you can convert the file directly.
Once you have access to the QCOW2 file, the importation command is quite simple:
qm importdisk <vmid> yourimage.qcow2 namestoragepool
This will take a bit of time as it has to copy the entire filesystem block by block. The <vmid> is just the numerical ID of the VM (you should have created a VM before getting started.) This is a number like 100, 101, etc.
So a real world example might be like...
qm importdisk 101 fileserver.qcow2 local-lvm
This works for many formats other than qcow2 as well. A straight block image in ISO / img format will work just fine, too. You will often see that when using dd to take a block image of an LVM snapshot.
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.
After being imported, you might not see the storage in your hardware. Just rescan for it.
qm rescan
-
Very easy to do, but hard to look up.
-
@scottalanmiller said in Import a QCOW2 Into Proxmox:
If you already have a QCOW2 file, either coming from another KVM system or converted from another format, to use it in Proxmox you need to import it because you cannot copy the files directly into the storage location.
It sure looks like you can copy image files straight in. It just has to be in the right directory / have the right file name according to the target VM ID.
https://pve.proxmox.com/wiki/Moving_disk_image_from_one_KVM_machine_to_another -
@scottalanmiller said in Import a QCOW2 Into Proxmox:
Very easy to do, but hard to look up.
Can be found on there wiki.
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VEhttps://pve.proxmox.com/wiki/Additional_ways_to_migrate_to_Proxmox_VE
-
@Pete-S You are correct. You can copy the the qcow2 into the default Proxmox location. That's what I did when I was testing.
-
I followed this instruction: https://serverfault.com/questions/843212/existing-kvm-vm-to-proxmox-ve
-
@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
-
@JaredBusch Since when?
-
@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.
-
-
My installation is using qcow2
-
@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.
-
@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:~#
-
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...
-
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.
-
Ok, it looks like I just need to import it and adjust it in Windows and then in proxmox when I am done.
-
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.
-
@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.
-
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.
-
@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