- 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.
If you have a Ubuntu 16/14 qcow2 image, it would be running one 'wget' command to have a running TRex
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>
There are advantages to both formats. There are tools to convert from one to the other. Perhaps it is best for both images to be produced and released in a verifiable manner rather than having community members needing to create there own images. It is important to continue to offer the virtualbox .ova file.
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).