Importing/exporting VMs or disks from VMware and RH[E]V/oVirt


Jun 27, 2023
With RHEV/oVirt/CentOS all being decomissioned, I am looking for a new home.

Proxmox is looking better than Xcp-ng in many ways, but even if those guys use Xen, migration facilities seem much easier and more mature. oVirt/RHV wasn't too bad at importing VMware VMs, but its own exports tend to only work with other oVirt instances, because everybody seems to do *.OVF files very differently and never tests against the competition.

In Proxmox I currently struggling at importing VMs or just their disk images mostly from oVirt/RHV, but also from VMware. While I don't mind recreating most of the VM parameters manually I do need the on-disks data of the VMs for which I am testing migrations.

The *.OVR files generated by oVirt seem nothing but tar'ed *.OVF, but when I try to use qm importovf on the unpacked files, I just get an error about a controller not being found with no easy way of fixing the XML file in a way that Proxmox understands.

The *.OVR, *.OVF file formats seems very losely defined and I've had tons of trouble with VMs coming from VMware (Workstation) and RHEV exports fail to be accepted by Proxmox, too: the error messages aren't helping and I haven't found where proxmox keeps the logs for the various activities yet.

Since it's all KVM and QEMU I don't think there are unsurmountable obstacles, yet I can't find any documented obvious way to upload a QCOW file to something NFS so that I can then migrate it onto the Ceph RDB storage as the operational target.

Nor does there seem to be any obvious way to download disk images or export VMs in a virtual appliance format.

Now I guess that could be done using QEMU tools, but direct qemu or libvirt access doesn't seem to fit into the proxmox philosophy, either.

I'd appreciate any pointers to some more in-depth documentation or how the CLI tools can be made to be a little more verbose or where I would have to look for logs.
One second after posting this, I found a post on importing the disk using "qm import disk" (syntax seems to have changed, but it seems to do the job...)

sorry... But there are some questions left over two answer ;-)
Now that original QCOW image inside the *.ovr TAR was quite sparse (only 7 of 200 GB used), but after extraction with tar it seems to have been fully allocated (well, on a gluster volume with VDO dedup/compression, but logically it was 200GB ) and after importing it also shows at 200GB on RBD.

I trimmed it and it reported trimming 183GB off that disk, but I can't seem to find any view which reflects if the actual allocation on the RDB store is the sparse size or the logical size. There are also no compression statistics visible in the GUI: will trimming just take care of it or do I need to change my filthy habit of logically allocating generous storage because I don't want to calculate what I'll actually need?
`rbd du` should tell you the allocated vs. provisioned space usage (either of one image or snapshot, or of all images in a pool)


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!