VMware Cloud Community
gftdbaamt
Contributor
Contributor

Disparity between Client OS data size and VMware Volume reported usage

I am having an issue understanding how the VI Client reports disk usage verses actual usage by the client OS. I came acros this when researching snapshot usage on another ESXi 3.5 box I am running. Any assistance here is greatly appreciated.

On this ESX server I have two clients, one Windows 2003 R2 Server, and one Windows 2008 Server. Each server has its own volume assigned to it on an iSCSI array(Intel Modular Server). Neither server has snapshot files associated with it.

I copied the Windows XP SP3 patch (316 MB) from an external NAS on our network to a Storage folder on the Windows 2008 Server, located in PrimaryVMwareStorage, to see what the impact would be. Here are the results. PrimaryVMStorage lost 2 GB of free space, and TrendMicroMessage lost 1 GB. Those are completely separate storage containers. Why would both be impacted? And why would a 300 MB file deplete 3 GBs of space? What is the "best practices" method to shring the vmdk files to a more manageable size? I'm just concerned that as soon as we really start moving our major network shares to the 2008 box, we're going to have problems.

Thanks to any that can clear up these questions for me.

0 Kudos
7 Replies
RParker
Immortal
Immortal

Well I am not really sure what you are asking. Storage is completely different and separate from VM Ware. so if you have a storage usage issue, you should talk to your storage vendor, that's not a VM ware problem. If you are asking about the OS, and the VMDK those are 2 separate issues also.

You buy a hard drive from the store, and it's a 100Gb disk. You only use 5Gb. So is your use 100Gb or 5Gb? You have space that's been allocated to you (100Gb) therefore that's the space you can use, and it's taken out of the available pool of storage (since it can't be used by anyone else). But the OS sees the amount used and free space, but it can't see the entire pool of resource only the amount it's been allocated.

Then there is NFS storage and LUN. LUN are pre-allocated from the beginning, and if you don't use nothing else can 'share' the unused portion, but NFS you can, because it doesn't require a pre-allocated LUN to give the space out from.

So I believe this is confusion on your part and your storage and how you have it allocated. So I would call your vendor or read the documentation on exactly HOW they provide space for your VMs.

0 Kudos
gftdbaamt
Contributor
Contributor

I apologies if my questions were unclear. Perhaps the below information will help.

Description

Size

Usage

Lun

300GB

NA

VI Client - Details

259.25GB

222.55 Used

Database Browser

230GB Used

Windows 2008 Server

219GB

16GB Used

Taking into account the log files and the swap file the reported size usage by the Database Browser and the VI Client details section on the volume still do not jive. Why does the VI Client report different information than the Database browser and why is "free" space use at an increased rate by VMware over the client OS?

0 Kudos
RParker
Immortal
Immortal

OK, nice details. However I see where you are getting confused.

Different SAN storage devices have different methods for setting up space. I think they pretty much ALL follow 1 rule when it comes to LUN allocation, that the VOLUME size has to be somewhat larger than the actual LUN being created. So from your perspective, maybe the volume you created to house the LUN is 300g, however the LUN needs additional overhead room at the volume level, because realistically a LUN is just a really big chunk of pre-allocated data in a Volume.

so 300g allocated to LUN (or Volume). VM Ware sees it as a 259G LUN (which tells me the actual LUN is only 260 or so G). VMFS doesn't need that much overhead, it's very small less than 1%, if that. So you lost 40Gb right there just in the SAN allocation for the LUN.

Filesystems allocate in block sizes, so depending on the block size, you lose more space for certain files. So a vmx is one file, the swap is another file, logs are another file, and there are 2 files that make up the VMDK, the header and the actually data VMDK. For this reason I turn off logs on LUN's because A) I rarely if ever need them (logs are on the ESX host, and any problems are probably at the host level, not VM level) and B) because if you have 100 VM's on a LUN with a 2Meg block size, do the math. That's quite a bit of wasted space just to preserve logs.

With respect to Windows, it's not clear is that how much you gave the VM, 219Gb? If so, then the usage should also be 219G on the LUN, but if the OS reports 19G out of the 219Gb, then that makes sense. So of the 259Gb VMFS you have setup for VM use, this 1 Windows VM is using 219GB, leaving 40GB of space free. The usage shows 222 which probably accounts for the logs, vmdk header, vswp, and vmx files along with the data VMDK on that VMFS, so that lines up correctly.

And what is the 'database' browser? Is that part of the built in SAN storage you have?

The rest of the space is just how much overhead is required for VMFS (proprietary file system) and the Volume, and RAID parity stripe data. There are still some 'unknown' factors, but this looks correct to me.

0 Kudos
gftdbaamt
Contributor
Contributor

I will give some more details to my current setup. I am well aware the LUN avaiable space will be less when using a redundancy scheme, in this case Raid 5 over 6 drives. The issue I have concerns about deal with how VMware utilizes the storage. I am using VMware Infrastructure Client 2.5.0 Build 119801 VMware ESX 3i 3.5.0 Build 123629. Within the VI Client choose the Configuration Tab, then Storage from the left menu under the Hardware header. This brings up the attached VMware Volumes. Right click one of the volumes to bring up an option to "Browse Datastore". This is built into the VI Client and lists the files within the volume. I have included this information below.

Windows 2008 AD-1.vmx

2.03KB

Windows 2008 AD-1.vmdk

230,686,700.00KB

Windows 2008 AD-1.nvram

8.48KB

vmware-1.log

427.13KB

vmware-2.log

98.13KB

vmware.log

84.95KB

Windows 2008 AD-1.vmxf

0.27KB

Windows 2008 AD-1.vmsd

0.00KB

Windows 2008 AD-1-cec99758.vswp

2,097,152.00KB

The client OS "drive" is set to 219GB and is utilizing 16GB of that. The vmdk file is stating it is 230GB in size which is larger than the Client allocation. My concern is the vmdk file will continue to grow and run the VMware volume out of space long before the client OS "drive" is full.

0 Kudos
RParker
Immortal
Immortal

The client OS "drive" is set to 219GB and is utilizing 16GB of that. The vmdk file is stating it is 230GB in size which is larger than the Client allocation. My concern is the vmdk file will continue to grow and run the VMware volume out of space long before the client OS "drive" is full.

Well it won't grow beyond the size specified in the vmx configuration. What size did you give it? 219GB? It won't grow beyond that. At least it should not, unless you involve snapshots, which I know you aren't using now.

VM doesn't size storage. It just uses whatever is available at the block size you set, and that's it. It doesn't do anything else beyond that. That's why I say it's how your volumes / drives are setup on the SAN. Some SAN have the ability to do snapshots also, this is outside of VM Ware snapshots, done at the file level. Some space gets reserved in case you need to make snapshots, if you don't those, then consider turning them off if you are not using, that could occupy space as well.

So if you right click the datastore, what are the properties for the datastore? It should be 259GB (or 260GB raw). The files withing the folders are taking into account files other than the VMDK files, so yes they will grow.

But what does the SAN (I am guessing database viewer) show for this Volume, and LUN? I think 300Gb, of which VMFS is using 260GB, of which x amount is allocated for this Windows 2008 AD-1 VM (not sure how much but based on sizes, I'd say 219Gb) and inside that guest OS it's using 19Gb of it's 219GB allocation. It won't grow beyond the scope of the drive parameters.

0 Kudos
RParker
Immortal
Immortal

I see where you are going with this a little more now.

You setup a VM of 219 Gb, but you look at the vmdk and you see this:230,686,700.00KB. Which is actually 230G not 219Gb.

File systems and RAID groups involve multiple layers of overhead. You start with a disk. A disk is comprised of platters and allocation units and interleave to give the drive a chance to read data with gaps in between, designed ways to allow 'fudge' errors and overflow. Now let's say you have a 300G disk. It's actually USABLE space is 266G (somewhat less than 300G).

now you put 5 of them together. That's 300 x 5 is 1.5 TB but in reality it's 266 x 5 minus RAID overhead which is now really 1396.98 (assuming you can truly get 300G of out the disks which you cannot). So it's really more like ~1290 or 1.29 TB of space.

Now you are ready to put them in the SAN and use them for storage. But RAW space is 1.29TB, but SAN vendors use some overhead to monitor and provision the disks, so now you are looking at probably 1.1 TB of USABLE space. NOW we have to put a LUN on that volume provision, but again LUN requires overhead.

NOW the biggest LUN you can create is probably 1TB (10% left over for room, some SAN vendors scrub for defrag etc..). So now REALLY you have less than a TB you can ACTUALLY use.

NOW you can put VMFS on that LUN, well guess what more overhead. So NOW you have 990GB of space left. NOW you are ready to put your VM's. But wait.. EACH VMDK is almost like a RAID group, within that VMDK in order to give you USABLE storage area at the size you wanted, you have ADD overhead.

so 219GB USABLE space of OS becomes a 230 GB file with built in overhead. And minimal space on a VMFS volume is a 1meg block size. ALL files less than 1 Meg automatically occupy 1 Meg of space, and that's ONLY if you use a 1 meg block size, if you gave it a bigger block size, that's each file consumes 2Meg of 2meg of size or less..

Now you see where this is going?

230 IS the size of your VMDK. It will not expand beyond that. But ADDITIONAL files not included in the original setup will impact your drive space usage, which is why you want to keep 'extra' space.. Smiley Happy

0 Kudos
gftdbaamt
Contributor
Contributor

My colleague found a great article which appears to be the answer to my question. I am posting the link to help others. Thank you for your efforts RParker.

0 Kudos