Any LUN block that was touched at least once remains in use forever. NetApp has no knowledge whether this block is on free list of file system on top of LUN or belongs to some file inside. In your case VMware did touch 180GB during its lifetime. Of them 120GB is likely on free list (or similar) of vmfs, and are accounted as "free" by it; but they still occupy space on NetApp.
Unless you can force VMware to reuse old blocks in preference to allocating new once, I do not see what can be done. Using raw disks is probably an option as was already mentioned.
? ????????? / With best regards / Mit freundlichen Grü?en
--- Andrey Borzenkov Senior system engineer
________________________________ From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of drenthjd@wxs.nl Sent: Wednesday, July 18, 2007 1:54 AM To: Kenneth Heal; toasters@mathworks.com Subject: RE: NetApp Thin Provisioning and VMware ESX
Forgot to mention, we have disabled all snapshotting on the NetApp, and space reservation configuration is as was mentioned.
DF output shows the 180 GB in use (while ESX reports 60 on the VFMS).
The TR talks about auto deletion and auto grow, which are fine and very helpful in general but do not adress this issue we are having.
It would seem while a static amound of VMDKs is in use, the strategy works for you. But when you delete and recreate a vmdk (either from scratch or a dumb copy) VMware will put this new file anywhere in the thin provisioned LUN - thus not reusing old vmdk space, thus taking up more space than strictly necessary (of course at the end of the empty void that is thin provisioned I suppose it would start using old removed spave, but that would render thin provisioning useless).
Kind regards, Delorean
________________________________ Van: Kenneth Heal [mailto:kheal@hotmail.com] Verzonden: di 17-7-2007 23:40 Aan: drenthjd@wxs.nl; toasters@mathworks.com Onderwerp: RE: NetApp Thin Provisioning and VMware ESX Hi
Don't know if you have seen http://www.netapp.com/library/tr/3428.pdf. This talks a bit more about ESX and Netapp together. Reading this description it sounds like there may be old snapshots and/or space reservations at play here. In the case of the former snapshot auto-deletion may prove to be a help.
Could you check this and grab us a df output?
I haven't tried this combo, so there may be someone out there who has already done this and could say more.
regards Kenneth Heal Storage Consultant Senet Eindhoven bv ________________________________ Subject: NetApp Thin Provisioning and VMware ESX Date: Tue, 17 Jul 2007 22:54:03 +0200 From: drenthjd@wxs.nl To: toasters@mathworks.com Hi Toasters,
We created something of an interesting dilemma for ourselves.
The original problem was the lack of a means to extend existing VMFS LUNs through ESX without an extent and or downtime.
The idea was to use NetApp thin provisioning as a way to offer up a large disk to ESX without the need to back that up with real disks, as a way to monitor real disk usage we created a hard volume and monitor with df the real use of disk against a hard limit (being the volume).
So a 1 TB Lun (thin) was created inside a 200 GB (hard) volume, subsequently we wanted to keep track of ESX 3's usage through controlling the size of the VMDK files we would create. As this environment hosts desktops and was a testing ground at first there were a whole bunch of VMDK being created and destroyed.
The situation we end up with is VMware thinking it has 60 GB in use of a 1 TB LUN while NetApp reports 180 GB in use of 200 GB (being the hard limit at this time).
Basically the question becomes whether we can force ESX to actually reuse any of the [netapp in use] - [real use according to ESX] = 130 GB of space.
Probably we need to clean up and start over with a new clean LUN, which we could then either hard provision and forget about thin provisioning altogether, because in our scenario it is no help. A broader question becomes were we went wrong? Our situation seems to suggest that we waste a whole lot of disk space - which VMware wont reuse on its own, and which NetApp can't touch (how would it know it was now freed up space) In that sense thin provisioning is just a space waster in an environment with VMDK's being destroyed and recreated from scratch.
Of course we could always go flexcloning... but that would force netapp world on a whole lot of admins.
Best regards, Delorean
________________________________ Change is good. See what's different about Windows Live Hotmail. Check it out!http://www.windowslive-hotmail.com/learnmore/default.html?locale=en-us&ocid=RMT_TAGLM_HMWL_reten_changegood_0607