This seems to be something that most people are forgetting to look at. The most common question I get is how big to make the “Transfer” space, however recently we ran into a situation where root on the cell filled up from logs and other items. It begged the question about how to size the cell, and I found out that is not actually documented anywhere as it relates to “How do I partition my Cell?” This has been long overlooked with the exception of the transfer space since that generally is mapped to NFS and the size can be changed on the fly.
Sizing aside, here is what I would recommend as the mount points used in the file system of the Linux machine running vCloud Director. You can adjust the sizes as needed, but I will admit this is not listed anywhere until now. Certainly let me know what you think about the actual sizes but this should be a good start and if nothing else check with you’re Linux System Admin’s to find out what they normally use.
- /opt – This one is where all the vCloud Director installs will go. If you ever turn up logging for example you could end up filling root if this is not a separate mount point. All VMware vCloud Director logs also land here as well.
When using multiple Cells we should all know by now that “/opt/vmware/vcloud-director/data/transfer” also get’s remounted to the NFS share. However it should be noted that if you do NOT do multiple cells, this space needs to have enough room for Virtual Machines being uploaded to vCloud Director. Therefore you want to make /opt large enough OR in turn move the transfer folder to another mount point after the vCloud Director installation.
This may seem pretty basic to most people, but maybe in a proof of concept the Linux operating system was not setup in an optimal fashion. If you are looking to deploy in production then you should re-examine if the Linux builds are mounting /opt or not and adjust accordingly. As far as sizing goes, that can be left up to you but at least this prevents the vCloud director logs from filling up the root partition especially if you crank up the logging for troubleshooting. You could certainly move the vCloud Director logs as well but that may not be needed.
Just know that most people I have seen are not creating /opt as a separate mount point and that is certainly causing some issues. I do see the other partitions getting created, but not /opt in many cases. Maybe because folks do not know until after they install that this is the location of the VMware vCloud Director installation files. This may seem very rudimentary but the fact I am not seeing it means some folks need a simple reminder that’s all.
on this partitioning of a Linux, the best practises documents almost always get their partitioning from 20+ years back. Those systems were used very differently from how we utilise Linux with VCD. For example, you definitely do not need /home, for the simple reason, you do not have users logging in and storing their private files on VCD cell server!
You forgot one obvious/mandatory partition from your list, the root, /. That is where all files (including /opt) go if you do not have a separate partition for them. As /usr is managed by operating system, and is not changing very much/almost all, I find it an useless partition on application servers. Also /tmp is really not used much. Only few megabytes max normally.
/var/log is the only growing directory on normally working app server. On VCD we obviously also need /opt, as that app and its logs are there. Wise men move their VCD logs to /var/log/VCD on another partition to be safe. Symbolic links are nice.
On VCD, /var is used only by OS when doing updates. Ok, there are some other smaller stuff there, too, but very small and stable.
I’ll throw in partitioning I have used on most of my VCD cell servers:
hard disk 1 — 25GB:
swap 5GB (forget old recommendations to have swap as 2x RAM)
hard disk 2 — 40GB:
Comments are appreciated!