summaryrefslogtreecommitdiff
path: root/docs/appendix/virtual/vyos-on-vmware.rst
diff options
context:
space:
mode:
authorChristian Poessinger <christian@poessinger.com>2020-09-11 22:49:23 +0200
committerGitHub <noreply@github.com>2020-09-11 22:49:23 +0200
commit5df2b6a3be0c07c44517592df2cef23f2659ea4a (patch)
treeccbdbbd6fb35807d25863c0efea11accbb68df57 /docs/appendix/virtual/vyos-on-vmware.rst
parent1b71305b9be53b7d3c192c7bad63f5ff1e4d76d4 (diff)
parentec9e4722a78746be3a9efda23a7828f19a4e54d8 (diff)
downloadvyos-documentation-5df2b6a3be0c07c44517592df2cef23f2659ea4a.tar.gz
vyos-documentation-5df2b6a3be0c07c44517592df2cef23f2659ea4a.zip
Merge pull request #323 from currite/appendix-reindex
appendix: reindex to nest virtual environments
Diffstat (limited to 'docs/appendix/virtual/vyos-on-vmware.rst')
-rw-r--r--docs/appendix/virtual/vyos-on-vmware.rst32
1 files changed, 32 insertions, 0 deletions
diff --git a/docs/appendix/virtual/vyos-on-vmware.rst b/docs/appendix/virtual/vyos-on-vmware.rst
new file mode 100644
index 00000000..c4299cbf
--- /dev/null
+++ b/docs/appendix/virtual/vyos-on-vmware.rst
@@ -0,0 +1,32 @@
+.. _vyosonvmware:
+
+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`.
+
+.. 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 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.
+
+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.
+
+
+
+
+
+References
+----------
+
+https://muralidba.blogspot.com/2018/03/how-does-linux-out-of-memory-oom-killer.html
+