VMware Cloud Community
andvm
Hot Shot
Hot Shot
Jump to solution

VM actual consumed space

Hi,

VM used space from vCenter VM properties is 15KB!

VM used space within VM OS (Linux) is 28GB

VM vmdk (stored on vSAN and default storage policy) and viewed via vCenter datastore file browse shows around 150GB

Why are there such big differences and which is the correct way to find out the real size of the vmdk?

How can I find or best estimate its size if I had to export it as ovf?

Thanks

0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
Jump to solution

Hello andvm

This can (unfortunately) be a bit of a complicated question as different places may have different *opinions* depending on how they calculate it (and a number of other factors) but I will do my best to clarify the situation.

"VM used space from vCenter VM properties is 15KB!"

Where exactly do you mean?

I would advise with starting with right-click the VM > Edit Settings > Hard Disk drop-downs > validate that it is pointing to the base disk (and not a snapshot) and it should show the size of the vmdk Object including what it is using for FTT and FTM.

"VM used space within VM OS (Linux) is 28GB"

This is going to be lower than what the actual size of the vmdk Objects use on vsanDatastore for a number of reasons including:

- This doesn't account for FTT and FTM (e.g. if you have RAID1,FTT=1 then it is going to be 2x this).

- This doesn't account for growth of the usage that has since decreased unless you have TRIM/Unmapped (e.g. if you have 40GB max ever used and get it down to 20GB, the Object will still be 40GB per RAID1 replica unless you TRIM/Unmap it).

- If the Object is either Thick-provisioned from the vmdk primitive level (e.g. EZT) or via Storage Policy being set to Object Space Reservation = 100

"VM vmdk (stored on vSAN and default storage policy) and viewed via vCenter datastore file browse shows around 150GB"

I have unfortunately found in some builds to be unreliable/problematic and even in later builds where a lot of the issues are fixed it still seems to be misleading (e.g. it can tell what a local RAID5/6 mirror consumes but not the full Object in a Stretched-cluster using PFTT=1,SFTT=1,local-protection FTM=RAID5/6)

"Why are there such big differences and which is the correct way to find out the real size of the vmdk?"

If it is compliant with its Storage Policy (and not a non-standard configuration like some form of linked or shared vmdk or stored in a namespace separate from its .vmx) then the usage in Edit Settings > select vmdk > dropdown or on 'Edit VM Storage Policies' when checking before change should show the correct value.

Other methods would include using 'esxcli vsan debug object list' or via RVC using 'vsan.vm_object_info <pathToVM>' or objtool getAttr on the vmdk Object

"How can I find or best estimate its size if I had to export it as ovf?"

Are you storing it as an vSAN Object or on VMFS? If storing it with the same Storage Policy as the original Objects then I would expect the size to be similar (which I would go by the usage as per Edit Settings above and validate with one of the 'other' options I mentioned).

Bob

View solution in original post

7 Replies
Alex_Romeo
Leadership
Leadership
Jump to solution

Hi,

The difference is in the type of virtual disk you create when you make a virtual machine:

Thick Provision Lazy Zeroed
Creates a virtual disk in a default thick format. Space required for the virtual disk is allocated when the disk is created. Data remaining on the physical device is not erased during creation, but is zeroed out on demand later on first write from the virtual machine. Virtual machines do not read stale data from the physical device.
Thick Provision Eager Zeroed
A type of thick virtual disk that supports clustering features such as Fault Tolerance. Space required for the virtual disk is allocated at creation time. In contrast to the thick provision lazy zeroed format, the data remaining on the physical device is zeroed out when the virtual disk is created. It might take longer to create virtual disks in this format than to create other types of disks. Increasing the size of an Eager Zeroed Thick virtual disk causes a significant stun time for the virtual machine.
Thin Provision
Use this format to save storage space. For the thin disk, you provision as much datastore space as the disk would require based on the value that you enter for the virtual disk size. However, the thin disk starts small and at first, uses only as much datastore space as the disk needs for its initial operations. If the thin disk needs more space later, it can grow to its maximum capacity and occupy the entire datastore space provisioned to it.

About Virtual Disk Provisioning Policies

ARomeo

Blog: https://www.aleadmin.it/
0 Kudos
andvm
Hot Shot
Hot Shot
Jump to solution

Thank you...sorry should have mentioned that it’s Thin provisioned.

I am still however with same question of trying to understand actual size of vmdk compared to used space from within OS

0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello andvm

This can (unfortunately) be a bit of a complicated question as different places may have different *opinions* depending on how they calculate it (and a number of other factors) but I will do my best to clarify the situation.

"VM used space from vCenter VM properties is 15KB!"

Where exactly do you mean?

I would advise with starting with right-click the VM > Edit Settings > Hard Disk drop-downs > validate that it is pointing to the base disk (and not a snapshot) and it should show the size of the vmdk Object including what it is using for FTT and FTM.

"VM used space within VM OS (Linux) is 28GB"

This is going to be lower than what the actual size of the vmdk Objects use on vsanDatastore for a number of reasons including:

- This doesn't account for FTT and FTM (e.g. if you have RAID1,FTT=1 then it is going to be 2x this).

- This doesn't account for growth of the usage that has since decreased unless you have TRIM/Unmapped (e.g. if you have 40GB max ever used and get it down to 20GB, the Object will still be 40GB per RAID1 replica unless you TRIM/Unmap it).

- If the Object is either Thick-provisioned from the vmdk primitive level (e.g. EZT) or via Storage Policy being set to Object Space Reservation = 100

"VM vmdk (stored on vSAN and default storage policy) and viewed via vCenter datastore file browse shows around 150GB"

I have unfortunately found in some builds to be unreliable/problematic and even in later builds where a lot of the issues are fixed it still seems to be misleading (e.g. it can tell what a local RAID5/6 mirror consumes but not the full Object in a Stretched-cluster using PFTT=1,SFTT=1,local-protection FTM=RAID5/6)

"Why are there such big differences and which is the correct way to find out the real size of the vmdk?"

If it is compliant with its Storage Policy (and not a non-standard configuration like some form of linked or shared vmdk or stored in a namespace separate from its .vmx) then the usage in Edit Settings > select vmdk > dropdown or on 'Edit VM Storage Policies' when checking before change should show the correct value.

Other methods would include using 'esxcli vsan debug object list' or via RVC using 'vsan.vm_object_info <pathToVM>' or objtool getAttr on the vmdk Object

"How can I find or best estimate its size if I had to export it as ovf?"

Are you storing it as an vSAN Object or on VMFS? If storing it with the same Storage Policy as the original Objects then I would expect the size to be similar (which I would go by the usage as per Edit Settings above and validate with one of the 'other' options I mentioned).

Bob

andvm
Hot Shot
Hot Shot
Jump to solution

Hi TheBobkin

Checked for another VM (as unable to check for this VM as will explain in last sentence) within the Web Client and yes it does show that info, seems HTML5 version does not have such info however:

Right-click the VM > Edit Settings > Hard Disk drop-downs > validate that it is pointing to the base disk (and not a snapshot) and it should show the size of the vmdk Object including what it is using for FTT and FTM.

Ok will not rely on vmdk size shown via vCenter datastore browser:

I have unfortunately found in some builds to be unreliable/problematic and even in later builds where a lot of the issues are fixed it still seems to be misleading (e.g. it can tell what a local RAID5/6 mirror consumes but not the full Object in a Stretched-cluster using PFTT=1,SFTT=1,local-protection FTM=RAID5/6)

I exported the VM as OVF template and it eventually seemed to be downloaded and completed even though progress status shows stuck at 33% . (Total vmdk size around 55GB)

The related issue I see now is that I cannot do certain actions on the VM such as Edit/Power ON (greyed out) because it probably is still locked thinking ovf is still in progress.

Its been like this for hours and vmdk looks to be complete (no .part) so not sure if there is any background process that checks/clears this automatically or if I should take any action?

Thanks

0 Kudos
andvm
Hot Shot
Hot Shot
Jump to solution

Had to cancel it at the end, ovf export looked to be fine as it imported ok.

Used space reported via VM Edit Settings is 155GB (using default vSAN storage policy) so unfortunately still cannot work out how it ended with a 55GB vmdk when exported via ovf

0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello andvm​,

Well the OVF won't have any FTT etc. so this will account for a lot of the space - can you share/PM me the output from RVC for this VM?

> vsan.vm_object_info <pathToVM>          (e.g. vsan.vm_object_info /localhost/DCName/computers/ClusterName/resourcePools/vms/VMName/ )

Bob

0 Kudos
andvm
Hot Shot
Hot Shot
Jump to solution

Hi TheBobkin

No worries I think this is enough for me to get a better idea an understand as you initially said that it is not straightforward.

The Export to OVF should compress the data thus resulting in a smaller vmdk when compared to the size of the disk via VM Edit Settings (i.e. for this instance /2 to take into account FTT)

0 Kudos