The VMAN Admin Guide references a great tool to forecast the storage requirements for VMAN. The Solarwinds Virtualization Manager Storage Calculator does a great job of forecasting the growth of your environment. We've had our VMAN install running for about 6 months now and we're within about 2% of the forecasted growth. That is where the problems start...
From the screenshot above you can see we have a very large VMAN footprint. The first issue is that we will outgrow the max size of the Master Boot Record (MBR) -- 2 TBs -- some time in the next 36 months based on the growth of our environment and data retention. That is solved via the process below sent to us via support. The second issue is overall disk size. Even if we didn't add any more hosts or VMs (which is not going to happen) we will outgrow our current max LUN size (a storage issue -- not a VMAN issue). We're going to do some testing using LVM to great a Volume Group to extend the GPT (GUID Partition Table) volume (/data) with multiple vDisks, but the question really ought to be -- WHY?
Why will our storage requirements grow to nearly 3TB in year 5? Is there a way to delete data after a fixed period of time? We roll data out of our NPM environment after 365 days after rolling it up on 7 day and 31 day intervals. Can VMAN do the same?
My storage team thanks you in advance 
***
Out of the box VMAN supports 2 TB for the MBR (Master Boot Record), so once you get beyond that which you have a ways to go then you will need to convert the disk to use GPT (GUID Partition Table).
Once you get to that stage follow the steps below.
Resizing the disk
1. Create a snapshot of the VM
2. Open the console. Use the one provided by VMware as you will need to have access to it when the machine boots up with the resized disk for the first time.
3. Execute 'sudo yum install epel-release -y'. This will add the repository containing the gdisk tool. If this instance of VMan isn't connected to the internet, you can just download gdisk on a different VMan machine using the yum command with the -- downloadonly option, transfer the package to the customer's appliance and install it using 'rpm -ivp gdisk-file-name', and skip steps 3 and 4.
4. Execute 'sudo yum install gdisk -y'
5. Execute 'sudo yum remove epel-release -y'
6. Execute 'sudo service tomcat stop'
7. Execute 'sudo service postgresql stop'
8. Execute 'sudo umount /dev/sdb1'
9. Execute 'sudo gdisk'
10. Enter /dev/sdb'
11. Ignore the warning, press 'w' and confirm the action by pressing 'y'
12. Restart the appliance
13. Check that VMan still runs without problems
14. Check that the partition table was successfully transformed to GPT using 'sudo parted -l'. The record for /dev/sdb should show that the partition table is GPT.
15. Shut down the appliance
16. Delete the snapshot. Otherwise it's impossible to resize the disk.
17. Edit the VM settings to add more disk space to Hard disk 2.
18. Create a snapshot just in case something bad happens while resizing the disk.
19. Start the VM and open the console. It will one or more of the following wuestions. Answer them according to the following key
