summaryrefslogtreecommitdiff
path: root/docs/appendix/vyos-on-vmware.rst
diff options
context:
space:
mode:
authorStephen James <stephenorjames@gmail.com>2020-01-11 23:34:32 -0500
committerStephen James <stephenorjames@gmail.com>2020-01-11 23:37:28 -0500
commit74c5a1fc3cf31ba5d6d3d5fe603768369f1a3e34 (patch)
treeea06c94dca1c8693053dd9d481638b92a084fe6b /docs/appendix/vyos-on-vmware.rst
parent689756182ba1e16df51315407cdc749e6136e0cc (diff)
downloadvyos-documentation-74c5a1fc3cf31ba5d6d3d5fe603768369f1a3e34.tar.gz
vyos-documentation-74c5a1fc3cf31ba5d6d3d5fe603768369f1a3e34.zip
Fix some typos and capitalizations
Diffstat (limited to 'docs/appendix/vyos-on-vmware.rst')
-rw-r--r--docs/appendix/vyos-on-vmware.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/appendix/vyos-on-vmware.rst b/docs/appendix/vyos-on-vmware.rst
index 6feb95ba..c4299cbf 100644
--- a/docs/appendix/vyos-on-vmware.rst
+++ b/docs/appendix/vyos-on-vmware.rst
@@ -1,6 +1,6 @@
.. _vyosonvmware:
-Running on VMWare ESXi
+Running on VMware ESXi
######################
ESXi 5.5 or later
@@ -14,7 +14,7 @@ using the normal process around `install image`.
Memory Contention Considerations
--------------------------------
When the underlying ESXi host is approaching ~92% memory utilisation it will start the balloon process in s a 'soft' state to start reclaiming memory from guest operating systems.
-This causes an artifical pressure using the vmmemctl driver on memory usage on the virtual guest. As VyOS by default does not have a swap file, this vmmemctl pressure is unable to
+This causes an artificial pressure using the vmmemctl driver on memory usage on the virtual guest. As VyOS by default does not have a swap file, this vmmemctl pressure is unable to
force processes to move in memory data to the paging file, and blindly consumes memory forcing the virtual guest into a low memory state with no way to escape. The balloon can expand to 65% of
guest allocated memory, so a VyOS guest running >35% of memory usage, can encounter an out of memory situation, and trigger the kernel oom_kill process. At this point a weighted
lottery favouring memory hungry processes will be run with the unlucky winner being terminated by the kernel.