Thick and Thin Provisioning: What Is the Difference?

Subscribe banner

In this article, we are going to consider the storage pre-allotment aspect of virtual deejay settings in detail and observe out what thick and thin provisioning are, how they differ, and which of these storage pre-allocation types is ameliorate for your infrastructure.

Thick Provisioning

Thick provisioning is a type of storage pre-allocation. With thick provisioning, the complete amount of virtual disk storage capacity is pre-allocated on the physical storage when the virtual disk is created. A thick-provisioned virtual disk consumes all the space allocated to it in the datastore right from the start, then the space is unavailable for use by other virtual machines.

There are two sub-types of thick-provisioned virtual disks:

  • A Lazy zeroed disk is a disk that takes all of its space at the time of its creation, merely this space may contain some old data on the physical media. This onetime information is not erased or written over, so information technology needs to be "zeroed out" before new data tin can exist written to the blocks. This type of disk can exist created more apace, simply its performance volition be lower for the first writes due to the increased IOPS (input/output operations per second) for new blocks;
  • An Eager zeroed disk is a disk that gets all of the required space still at the time of its creation, and the space is wiped make clean of whatever previous data on the physical media. Creating eager zeroed disks takes longer, considering zeroes are written to the entire disk, but their performance is faster during the first writes. This sub-type of thick-provisioned virtual disk supports clustering features, such equally fault tolerance.

Thick provisioning

For information security reasons, eager zeroing is more than common than lazy zeroing with thick-provisioned virtual disks. Why? When you delete a VMDK, the data on the datastore is not totally erased; the blocks are only marked as available, until the operating organisation overwrites them. If you create an eager zeroed virtual disk on this datastore, the disk area will be totally erased (i.e., zeroed), thus preventing anyone with bad intentions from being able to recover the previous information – even if they utilise specialized third-party software.

Thin Provisioning

Thin provisioning is another type of storage pre-allocation. A sparse-provisioned virtual disk consumes only the space that it needs initially, and grows with time according to demand.

For instance, if y'all create a new sparse-provisioned 30GB virtual deejay and copy 10 GB of files to it, the size of the resulting VMDK file will be ten GB, whereas you would have a 30GB VMDK file if you had chosen to utilize a thick-provisioned deejay.

Thin Provisioning

Sparse-provisioned virtual disks are quick to create and useful for saving storage infinite. The operation of a thin-provisioned deejay is not higher than that of a lazy zeroed thick-provisioned disk, considering for both of these disk types, zeroes have to be written before writing information to a new block. Note that when you lot delete your data from a thin-provisioned virtual deejay, the disk size is not reduced automatically. This is considering the operating system deletes only the indexes from the file table that refer to the file trunk in the file system; information technology marks the blocks that belonged to "deleted" files as free and attainable for new data to exist written onto. This is why we run into file removal every bit instant. If it were a total deletion, where zeroes were written over the blocks that the deleted files occupied, it would take nigh the same amount of fourth dimension equally copying the files in question. See the simplified illustration beneath.

View from the operating system

Issues That May Occur When Using Thin-Provisioned Virtual Disks

Using thin-provisioned virtual disks is not always smooth. There are some issues that yous should exist aware of and prepared to deal with.

Let'due south consider an example that renders the virtual machines unusable. For instance, we have a 20GB datastore with three virtual machines running on information technology. Each virtual machine has a thin-provisioned virtual disk set with a maximum size of ten GB. (This exercise is called "overprovisioning" – we assign virtual disks more space than they tin physically take up. This is done frequently, equally it allows y'all to scale the arrangement by adding more physical storage equally yous need information technology.) The file size of each virtual disk will expand as data is added, until there is no gratis space left on the datastore. The state of affairs becomes disquisitional when at that place is simply 1GB of free space left on the datastore, as when, for example, VM1 occupies eight GB, VM2 occupies 7 GB, and VM3 - four GB.

Regular methods of file deletion inside virtual machines will not help compress the thin-provisioned virtual disks. If more 1 GB of new data is written to whatever of these virtual machines, all three of them will neglect, and you lot will need to drift one or more of the virtual machines to some other datastore to restore their running states.

How to Reduce the Size of Thin-Provisioned Virtual Deejay After Deleting Files

To be able to reduce the VMDK file size of your thin-provisioned virtual disks, you demand to know how to cypher the blocks that the data you deleted previously occupied. Let's notice out how to do that.

NOTE: Deejay shrinking operations are merely possible if the virtual machines do not contain snapshots. As well, please be attentive and execute commands at your own responsibility. Always back up all of your important information before carrying out any disk operations. To back upwardly your VMware and Hyper-Five virtual machines, apply NAKIVO Fill-in & Replication.

Shrinking Thin-Provisioned VMware Disks in Linux

Let's consider an instance: we have a 10,266,496 KB (10GB) VMDK file (nosotros learned about its size by going to the directory on the datastore where our virtual machine is located) and want to shrink the virtual disk on which the guest Linux OS is installed. We can try to delete unnecessary files on this virtual disk. Nevertheless, Linux does not automatically zero blocks afterwards deleting files; yous will take to do this yourself. Yous can do this by using the dd (data duplicator) utility for copying and converting data. This tool is available on all Linux systems.

Note: Before running the dd utility, it is necessary to brand sure the datastore has enough capacity to use it (east.g., for ESXi server, you can bank check the storage chapters in the storage department of the vSphere client – go to Configuration >> Storage).

Let's use the dd utility.

  1. First, nosotros cheque the free space on a guest Linux virtual machine by using the df -h control:
                  root@test-virtual-machine:/# df -h            

    We get the post-obit output in the console:

    Filesystem   Size   Used   Avail   Employ%   Mounted on  			udev         469M   0      469M    0%     /dev  			tmpfs        99M    six,3M   92M     7%     /run  			/dev/sda7    17G    8,8G   6,4G    58%    /  			tmpfs        491M   116K   491M    1%     /dev/shm  			tmpfs        5,0M   four,0K   five,0M    ane%     /run/lock  			tmpfs        491M   0      491M    0%     /sys/fs/cgroup  			/dev/sda1    945M   121M   760M    14%    /boot  			/dev/sda6    three,7G   13M    3,5G    1%     /var/log  			tmpfs        99M    36K    99M     1%     /run/user/grand            

    We can run into from this output that the / (root) partition contains 8.eight GB of files.

  2. Let's delete a few gigabytes of unnecessary files in the root partition. This is what we see in the panel, if we run the df -h / command:
                  Filesystem   Size   Used   Avail   Use%   Mounted on  			/dev/sda7    17G    4,7G   11G     31%    /            

    Thus, our root partition at present contains 4.seven GB of files. Still, going to the directory where our VMDK file is located, nosotros can see that its size is still 10,266,496 KB (x GB).

  3. Now we are going to fill the free space with zeroes (in our instance, we'll fill 10 GB out of eleven GB available). First, we blazon cd followed by the name of the directory that the partitioning that needs to be zeroed out is mounted to (in our case it is cd /, because we want to navigate to the root partition). After that, we run the following command, changing the variables to suit our needs:
                  dd bs=1M count=10240 if=/dev/zip of=zip            

    In this control:

    - dd can only exist run as super user.

    - bs sets the cake size (for example, bs=1M would requite you a 1-Megabyte block size).

    - count specifies the number of blocks to be copied (the default is for dd to go along going forever or until the input runs out). In our case, x,240 MB is the corporeality of free space that we want to fill with zeroes, and so the number of 1-Megabyte blocks is 10240.

    - if stands for "input file". This is where you lot should indicate the source from which you want to copy data. In our instance, it is /dev/naught – a special file (a pseudo-device) that provides every bit many null characters as y'all want to read from it.

    - of stands for "output file". This is where you set the destination where you want to write/paste your data (in our case, the name of the file is nix).

    Afterward executing the above command, the size of our VMDK file grows. This is the output nosotros see after the successfully completed command:

                  10240+0 records in  			10240+0 records out  			10737418240 bytes (10 GB) copied, 59,4348 s, 181 MB/s  			Command has been completed successfully.            

    So, now the size of our VMDK file is xi,321,856 KB (10.viii GB), meaning that it has expanded. Besides, if we run the df -h / control again, we will see the following:

                  Filesystem   Size   Used   Avail   Employ%   Mounted on  			/dev/sda7    17G    15G    569M    97%    /            

    This means that almost the whole root sectionalization (i.due east., 97%) is occupied. This is because we have filled nearly of the previously "available" infinite with zeroes. Now, our thin-provisioned virtual deejay is ready to be shrunk.

    Note: To perform shrinking, it is necessary to install VMware Tools.

  4. For virtual machines that are running on VMware ESXi or VMware Workstation, we execute the post-obit ii commands in the Linux guest Os.a) To make certain that the disk partition is available, nosotros run the command:
                  root@examination-virtual-machine:/# vmware-toolbox-cmd disk list            

    This is the output we see in our instance (i.due east., we see the listing of available partitions):

                  /  			/kicking  			/var/log            

    The root segmentation is present, so we tin can proceed.

    b) To shrink the partition, nosotros run the following control:

                  root@test-virtual-machine:/# vmware-toolbox-cmd disk shrink /            

    This is the output we come across in our instance:

                  Please disregard whatever warnings well-nigh disk space for the duration of shrink process.  			Progress: 100 [===========>]  			Disk shrinking consummate.            

    Now, the size of our shrinked VMDK file is five,323,456 KB (that is, 5.08 GB – much less than the ten.viii GB it was before).

Annotation: If your guest virtual machine is running on an ESXi server, after filling the blocks with zeroes, you can follow these steps:

  1. Ability off the virtual machine, or disconnect the virtual deejay you want to shrink.
  2. Connect to the ESXi host with the SSH customer.
  3. Navigate to the Virtual Machine Folder.
  4. Verify deejay usage with du -h.
  5. Run vmkfstools -Thousand test-virtual-automobile.vmdk.
  6. Verify disk usage with du -h over again.

NAKIVO Backup & Replication Gratis Edition – the #1 gratuitous data protection solution that tin exist installed on both Linux and Windows.

Shrinking Sparse-Provisioned VMware Disks in Windows

Like Linux, Windows does not automatically nix blocks subsequently deleting files. To be able to naught the gratuitous space of the target disks on your Windows virtual machine, you need to download SDelete – a free utility from the Microsoft'southward Sysinternals Suite – and unzip the files from the downloaded archive to c:\plan files\sdelete.

Then follow these steps:

  1. Run cmd.
  2. Go to the directory where SDelete is located. In our case, it is:cd c:\programme files\sdelete
  3. For each partitioning in the console, utilise the sdelete -z command. This is what nosotros have in our case:
                  sdelete -z c:  			sdelete -z d:            

    These commands volition zero out any free space on your thin-provisioned deejay past filling in any unused space on the specified partitions.

    Look a couple of minutes until the procedure is finished. Your VMDK file will expand to its maximum size during the procedure.

  4. Make sure VMware Tools are installed on your Windows virtual auto. Past default, VMware Tools are installed to c:\program files\vmware\vmware tools\. Navigate to this directory by typing: cd c:\program files\vmware\vmware tools\.
  5. To view the available disk partitions, blazon:vmwaretoolboxcmd disk listing
  6. Shrink the disk partitions that yous demand. In our case, we ran the commands:
                  vmwaretoolboxcmd disk compress c:\  			vmwaretoolboxcmd disk compress d:\            

    Await until the program has finished shrinking the deejay.

You tin use this method for virtual machines that are running on VMware ESXi or VMware Workstation.

VMware Storage Distributed Resource Scheduler

Above, we mentioned a solution to shrink thin-provisioned disks manually. However, there is one more style to manage your virtual disks (both thin-provisioned and thick-provisioned), if you use a datastore cluster in vSphere. VMware provides automatic virtual disk migration inside the datastore cluster to avoid overflow of deejay storage where thin-provisioned virtual disks are located and to balance I/O resources. If yous have more than one shared datastore mounted to the ESXi server, you can prepare the Storage Distributed Resources Scheduler (Storage DRS). Storage DRS is an intelligent vCenter Server feature for efficiently managing VMFS and NFS storage that provides automatic virtual machine deejay placement and migration. You tin can too set Storage DRS to manual mode if you prefer to approve migration recommendations manually.

Follow these steps to enable Storage DRS:

  1. Navigate to the datastore cluster in the vSphere Web Client.
  2. Become to vCenter >> Datastore Clusters.
  3. Select your datastore cluster and click Manage >> Settings >> Services >> Storage DRS.
  4. Click Edit.
  5. Configure the automation settings, I/O-related functions, and advanced options that you demand.datastore-cluster
  6. Click OK to terminate.

If at that place are no datastore clusters in your vSphere environs, follow these steps to create and set up a new datastore cluster:

  1. Navigate to vCenter >> Datacenters in the vSphere Web Client.
  2. Right-click on your Datacenter and select New Datastore Cluster.
  3. Enter the proper name of your datastore cluster and tick the checkbox about "Turn On Storage DRS".
  4. Select the automation settings, I/O-related functions, and avant-garde options that y'all demand.
  5. Click OK to terminate.

Conclusion

In this blog mail, nosotros have considered the types of virtual disks and weighed the advantages and disadvantages of each in club to amend understand the differences between thick and sparse provisioning. Eager zeroed thick-provisioned disks are the all-time for performance and security, but require plenty costless storage space and take a lot of time to be created. Lazy zeroed thick-provision disks are good for their short creation times, just they do not provide as much speed equally eager zeroed disks do, and are less secure. Thin-provisioned disks are the best choice to save datastore space at the moment of disk creation. You lot tin create a virtual disk with a greater maximum size than the physical space you take available ("overprovisioning") and add more physical storage in the future, just call back that if the physical disk space fills upward and the thin-provisioned disk cannot grow to accommodate more than data, your virtual machines will get unusable – so don't forget to continue an eye on the amount of free space. We also went through methods of shrinking thin-provisioned VMware virtual disks, in instance you prefer non to add together more storage and demand to reduce the space taken.

VMware Backup