Why VHDX showing massively larger once converted to QCOW2?

automation_5

New Member
Sep 15, 2023
3
0
1
I did a P to V for a windows machine that created a 175GB vhdx file and then when converting the vhdx file to qcow2 it now shows as 1TB, this makes no sense?
The following command is what I used to convert the file:

Code:
qemu-img convert -O qcow2 DELLM4400.vhdx DELLM4400.qcow2 -p
 
Was your original disk size 1TB? Perhaps VHDX file is compressed/sparse. You can take a look at "man qemu-img" and try out various options to convert to see if that helps:
Code:
      convert [-C] [-c] [-p] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-B backing_file] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-m num_coroutines] [-W] [-S sparse_size] filename [filename2
       [...]] output_filename
           Convert the disk image filename or a snapshot snapshot_param(snapshot_id_or_name is deprecated) to disk image output_filename using format output_fmt. It can be optionally compressed ("-c" option) or use any format
           specific options like encryption ("-o" option).

           Only the formats "qcow" and "qcow2" support compression. The compression is read-only. It means that if a compressed sector is rewritten, then it is rewritten as uncompressed data.

           Image conversion is also useful to get smaller image when using a growable format such as "qcow": the empty sectors are detected and suppressed from the destination image.

           sparse_size indicates the consecutive number of bytes (defaults to 4k) that must contain only zeros for qemu-img to create a sparse image during conversion. If sparse_size is 0, the source will not be scanned for
           unallocated or zero sectors, and the destination image will always be fully allocated.

           You can use the backing_file option to force the output image to be created as a copy on write image of the specified base image; the backing_file should have the same content as the input's base image, however the
           path, image format, etc may differ.

           If a relative path name is given, the backing file is looked up relative to the directory containing output_filename.

           If the "-n" option is specified, the target volume creation will be skipped. This is useful for formats such as "rbd" if the target volume has already been created with site specific options that cannot be supplied
           through qemu-img.

           Out of order writes can be enabled with "-W" to improve performance.  This is only recommended for preallocated devices like host devices or other raw block devices. Out of order write does not work in combination
           with creating compressed images.

           num_coroutines specifies how many coroutines work in parallel during the convert process (defaults to 8).



Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
That actually explains alot, this is what the output is showing and not sure why virtual size is so large? I also used sysinternals disk2vhd tool to create the vhdx file @bbgeek17.

root@pm-03:/mnt/pve/backups/images/168# qemu-img info DELLM4400.VHDX
image: DELLM4400.VHDX
file format: vhdx
virtual size: 932 GiB (1000204886016 bytes)
disk size: 166 GiB
cluster_size: 2097152
 

About

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!