qcow2 image format.

• Would it be possible to export releases of the VM in qcow2 too.  For GNS3 integration would be much simpler then:Could create a template (aka appliance) file for QEMU VMs and, using that, users can import the VM with a few clicks. (Here's an example.)
• converting a vmdk to qcow2 is quite easy but we're checking the md5sum of the image file during import, and not sure if users would get the same hash for their local conversions.

We can do what you are asking.

Just to understand. Is QEMU VM better than virtual box.

we already have virtual box image. see here<https://trex-tgn.cisco.com/trex/doc/trex_vm_manual.html>

we did not give much thought into running Trex in these virtual scenarios. Because it is a tool aimed for performance, we assumed there will not be much interest in this case. The virtual box today has old version, and you need to get in, get new sources, and compile after installation (not too complicated, but requires some work).  We will consider automating the process.

• Need to convert the image  and download and configure TRex on a Linux box. In addition, even if users can create the images, it's very hard to check the result because the MD5 hash of the created images will be different. How would I check if the image is corrupt then.

GNS3 with QEMU can create linked clones of the original image when a device is pulled into the GNS3 topology, enabling the user to run multiple instances of a VM and re-use the same base image in another project.

VirtualBox supports linked clones too but creating and destroying the clones needs more manual work.

Supporting both would give the GNS3 users a huge advantage in testing their virtual topologies with real data, even if the performance can't be guaranteed (at least functional testing can be done).