Support appliances that come as .ova files.

[grossmj]

Should we automatically extract the OVA to get the needed file for Qemu (VDMK): http://www.unetlab.com/2014/11/juniper-firefly-perimeter-vsrx/

Side note: I don't think it is necessary to convert the vmdk files to qcow2

[julien-duponchelle]

qcow2 allow to use linked clone isn't it?

One issue with ova is we can get multiple disk. How can we handle it in the gns3a file? And also a disk could be split in multiple vmdk.

One options is:

   "images": [ 
        {
            "filename": "openwrt-14.07.ova",
            "version": "14.07",
            "md5sum": "2411307d0794baa618537c5dfcb19575",
            "filesize": 2183520,
            "download_url": "http://downloads.openwrt.org/barrier_breaker/14.07/realview/generic/",     
            "direct_download_url": "openwrt-14.07.ova"            
        },
        {
            "ova_source": "2411307d0794baa618537c5dfcb19575",
            "filename": "GNS3_VM-disk1.vmdk",
            "version": "14.07",
            "md5sum": "2411307d0794baa618537c5dfcb19575",
            "filesize": 2183520,   
        }
    ],

[julien-duponchelle]

We can uncompress the ova an keep it in the Qemu directory named by the original ova filename.

For example:
~/GNS3/images/QEMU/openwrt-14.07.ova/

But this require to support upload of directory when images are missing.

[julien-duponchelle]

NB: An another issue with VMDK, is the file can be split in smaller part. When can't compute a md5sum on a disk.

[julien-duponchelle]

A possible syntax for a file stored in an OVA:

    "versions": [
        {
            "name": "1.1.6",
            "images": {
                "hda_disk_image": "vyos.ova/disk1.vmdk"
            }
        }

[julien-duponchelle]

Strange the mail from Bernhard Ehlers is not visible on Github :(

On Fri, Oct 2, 2015 at 5:23 PM Bernhard Ehlers notifications@github.com
wrote:

Side note: I don't think it is necessary to convert the vmdk files to qcow2

Objection, your honor [image: 😄]

All the following is tested on debian jessie with qemu v2.1.2.

Lets use my http://bernhard-ehlers.de/projects/netem/NETem-v2.ova as an
example, it was build with VMware Fusion 8.

When you extract the ova with tar you get a NETem-disk1.vmdk, which is
20689408 bytes long

The ovf says about this vmdk:

Interesting are two facts:

• It's stream-optimized, I assume that means it's compressed to
  minimize the transport size
• There are 22544384 bytes data in it, more than the actual file size

When you try to use this vmdk with qemu, you get

behlers@dell:~$ qemu-system-i386 -hda NETem-disk1.vmdk
qemu-system-i386: -hda NETem-disk1.vmdk: could not open disk image NETem-disk1.vmdk: VMDK version 3 must be read only

When you convert it to "real" vmdk, you get a bigger file, roughly the
size the .ovf has told us.

behlers@dell:$ qemu-img convert -O vmdk NETem-disk1.vmdk NETem-disk2.vmdk
behlers@dell:$ ls -l NETem-disk2.vmdk
-rw-r--r-- 1 behlers behlers 22609920 Okt 2 17:07 NETem-disk2.vmdk

And that vmdk works in qemu.

That's just one example, I've seen that on other ova as well.

Therefore it's not enough to extract the vmdk out of an ova, it must be
converted. It really doesn't matter, if you convert it to vmdk or qcow2.
But as qcow2 is the native format, I suggest to use that.

—
Reply to this email directly or view it on GitHub
#15 (comment).

[julien-duponchelle]

Interresting mister @Ehlers . This mean we have no choice we need to convert the vmdk to qcow2 if we want to support all the format.

[ghost]

Don't panic, it's not necessary to convert the vmdk. I was wrong, therefore I deleted my comment.

In GNS3 the vmdk is not used directly (what wouldn't work), but as the base of a differential image. And that works well.

[julien-duponchelle]

Ok thanks for the informations

[julien-duponchelle]

I will implement this next week in order to allow people to quickly test.

[julien-duponchelle]

GNS3/gns3-gui#700