Merge pull request #579 from srividya0208/proof-reading

Proof reading

1 files changed, 23 insertions, 10 deletions

diff --git a/docs/installation/virtual/vmware.rst b/docs/installation/virtual/vmware.rst
index 6feb95ba..8f201920 100644
--- a/docs/installation/virtual/vmware.rst
+++ b/docs/installation/virtual/vmware.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-24

+

 .. _vyosonvmware:

 

 Running on VMWare ESXi

@@ -6,20 +8,31 @@ Running on VMWare ESXi
 ESXi 5.5 or later

 *****************

 

-.ova files are available for supporting users, and a VyOS can also be stood up using a generic Linux instance, and attaching the bootable ISO file and installing from the ISO 

-using the normal process around `install image`.

+.ova files are available for supporting users, and a VyOS can also be stood up 

+using a generic Linux instance, and attaching the bootable ISO file and 

+installing from the ISO using the normal process around `install image`.

 

-.. NOTE:: There have been previous documented issues with GRE/IPSEC tunneling using the E1000 adapter on the VyOS guest, and use of the VMXNET3 has been advised.

+.. NOTE:: There have been previous documented issues with GRE/IPSEC tunneling 

+   using the E1000 adapter on the VyOS guest, and use of the VMXNET3 has been 

+   advised.

 

 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

-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.

-

-It is advised that VyOS routers are configured in a resource group with adequate memory reservations so that ballooning is not inflicted on virtual VyOS guests.

+When the underlying ESXi host is approaching ~92% memory utilisation it will 

+start the balloon process in 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 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.

+

+It is advised that VyOS routers are configured in a resource group with 

+adequate memory reservations so that ballooning is not inflicted on virtual 

+VyOS guests.