时间:14-08-27 栏目:vmware虚拟化 作者:恒镭, 张 评论:0 点击: 7,852 次
Total allocated space that the virtual machine can commit up to. Includes vmdk, swap, snapshot, and other virtual machine files such as NVRAM, configuration files, and logs. This metric includes uncommitted space.
This metric is equivalent to Provisioned Storage in the Summary tab of the vSphere Client.
可见置备空间包括vmdk、swap, snapshot, and 等可能会消耗空间的空间。
怎么样用vsphere api 获取 datastore 置备空间呢？
I recently had some conversations around capacity monitoring of datastores and the topic of what is the uncommitted space came up. Uncommitted space can be dangerous if not paid close attention to. So what is uncommitted space and where does it come from you ask? Well, I’ll tell you.
Uncommitted space is either from Thin-Provisioned VM disks, Snapshots or Linked Clones. Uncommitted space is the difference of how big the disk size is vs. the currently consumed size. Here is a breakdown of a particular example.
You have a datastore that is 500GB in size. We have 300GB of free space in this datastore. You would see this as 40% Used. What we need to calculate is this…
((((Datastore Capacity – FreeSpace) + Uncommitted Space) *100) / Datastore Capacity)
Before we dive into filling out this equation let’s assume we have a thick provisioned Windows VM with 4GB RAM, a 50GB C Drive and a 150GB D Drive and we take a snapshot including the VM Memory. This VM has been running for a few days and we have a total of 10GB of snapshots. This means that the VM has 2 X 4GB vmswap files, 2 X 50GB vmdk’s for C Drive and 2 X 150GB vmdk’s for D Drive, which breaks out to 408GB max total space for this VM if every block changed. This info tells us that although the VM is currently consuming 4GB RAM, 50GB C Drive and 150 GB D Drive plus 10GB snapshots totaling out to 214GB there is now 408 – 214 = 194GB Uncommitted space. Now let’s use the above formula with this new data.
((((500 – 300) + 194) * 100) / 500) = 78.8
We now look at this datastore as 78.8% Allocated. This example still allows us room to grow, but you can imagine that if there is enough uncommitted space from multiple VM’s and blocks keep changing then you will potentially over-allocate the entire datastore and risk the datastore filling up and I am sure we have all experienced a datastore filling up.
Some basic recommendations I have are to pay close attention to snapshots if you use Snapshot based backup technologies like Veeam, Symantec NetBackup etc. These snapshot based backup utilities don’t always clean up their snapshots and you may find many lingering snapshots in your environment that you didn’t even know existed.
You should be able to use a few of the properties of a VMware.Vim.DatastoreSummary object (reference athttp://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.Datastore.Summary.html). There is not a "ProvisionedSpace" property, but you can calculate it from:
Maximum capacity of the datastore, in bytes
Available space of the datastore, in bytes
Total additional storage space, in bytes,
potentially used by all VMs on the datastore
Since provisioned space is sum of used space (which is capacity - freeSpace) and the uncommitted bytes, the simple math would be something like:
置备率 = 置备空间/总空间