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-
Sent: Wednesday, July 18, 2007
1:54 AM
To: Kenneth Heal;
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;
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:
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!