Change in size of ova when exported

[Eshwar1116]

Hi All,

I have an RHEL image with some software installed on one of my VM. When i shutdown and exported for the first time the size was 14.4GB. After some time i restarted and played for some time and exported back, surprisingly it was 9.45GB. I have no idea how this dramatic change has happened. For my perspective the installed software and RHEL are not more than 7GB.

I wonder why it went to 14.4GB and down to 9.45GB.

I just can't leave this unknown, please let me know your valuable feedback on this

The exported ova is working absolutely fine. I haven't changed anything

Details:

1) I am using ESX 4.1

2) My Virtual disk size is 60GB, and in both the cases(smaller size and larger size) i exported using thin proisioning.

3) Every time i export the image it is the same 9.45GB that is exported.

Thanks & Regards

Eshwar

[mydearcosmo]

Check on the files and programs you have downloaded and installed in your system. There might be one of them that eats a lot of your storage that leads to a dramatic dropdown in size.

[Eshwar1116]

There is no regular file which is larger than 500MB in the whole system.....

Thanks

Eshwar

[continuum]

A vmdk inside an OVF/OVA package uses the format "streamoptimized" and not "vmfs" thin provisioned.
the streamoptimized format is "packed" better - that explains the difference in size

[Eshwar1116]

Hi Continuum

When I was creating a VM i choosed thin provisioning under the disk provisioning section and exported with ova format

I didn't get your post...Can you explain in details....

Thanks

Eshwar

[continuum]

inside the OVF/OVA package you will find a vmdk - is this the one you are talking about ?

[Eshwar1116]

yes, the actual size of the vmdk is 60GB but when creating the virtual machine i have choosed thin provisioning.

When I exported, the ova size is 9.45GB

Observation :

1) I think the vmdk inside the ova is stream optimized, the reason is when i deploy the ova in ESX 4.1 it depolyed and works perfectly.  As ESX 4.1 only accepts stream optimized disk

Continuum

     Is there anything that is missing in my answer for your clarity ?

[continuum]

OVAs are tar archives - maybe that explains the size difference ?

I do not know what eactly surprises you ?

[Eshwar1116]

I have exported the same virtual machine twice in a gap of 2 days by playing a bit in between

the first day when i export it, it was 14.4GB and after playing(installed some new softwares) with it, it was 9.45GB

This difference has surprised me....

I hope u got it..........

Thanks

Eshwar

[continuum]

A thin provisioned vmdk does not reduce its size all by itself.

So either you are witness of a miracle or I still dont get it

[pbannister2]

I have seen - repeatedly - similar results. The size of the exported OVA/OVF is usually much larger than the amount of data in the filesystem. The exact size of the export can vary by a huge amount, depending on ... not sure exactly what. We have played around to get smaller sizes (dropping gigabytes when the contained data is still the same size), but what exactly the ovftool is doing internally ... dunno.

There is something rather funky about the OVF export. Maybe this is due to an inability of the tool between disused data in the free space of the filesystem captured, and data actually in use? Just a guess.

As a user of ovftool (and VMware Studio), I want the generated OVF to be as small as possible. I would hope the tool would only capture live filesystem data, ignore garbage in free space, and compress the result. From the results we see, that is not happening. (Also, in our experience, the compress option to ovftool does not do very much.)

There is an issue here, but figuring out what is going to take a concerted effort from someone working on ovftool.

[continuum]

> As a user of ovftool (and VMware Studio), I want the generated OVF to be as small as possible.

then wipe the unused diskspace inside the guest first.
sdelete on Windows or dd on Linux can do that.

After that the exported vmdk will be as small as possible

[pbannister2]

That might be good advice, but that then raises the obvious question:

If this is necessary, why is this not part of the standard behavior of VMware Studio?

When generating an OVF/OVA from VMware Studio, for distribution it does  make quite a difference between a 7 and 14GB OVA. Seems that minimizing  the size should be a definite goal. This is even somewhat true when  exporting from the vSphere client.

After all, VMware Studio does know quite a lot about the VM built. Zeroing out free space is possible within the VM. (This has the side-effect of inflating thin-provisioned disks, which can be expensive - though perhaps possible to short-circuit?). Better would be to zero out only garbage, or copy just the live data to a new VMDK before export.

If not implemented in VMware Studio, this should at least be mentioned as guidance in the documentation, somewhere.

I am not entirely convinced that garbage in the file system free space is the whole story. Some of our experiments seemed to indicate that the exact path through ovftool (local versus remote exports) and the structure of underlying storage had a large effect. These are very tedious experiments, so we have not explored every possibility....

You did ask the original poster to move this thread from the VMware Studio section, to here. Are you going to want to move it back? :smileyhappy:

[Eshwar1116]

Continumm

     dd has helped to reduce the size even more....from 9.45 to 6.5GB.

     Thanks for the help.....................

But i don't have a proper reason as why it is reducing the size dramatically......

     Can I have some kind of tool or something so that i can compare 14.5GB , 9.45GB and 6.5GB to know what is the exact reason...........

          One of the reason might be as u said the wipe out the free disk space....but is that the only reason i am not sure.........