From 7a85ac512aadf03eb73242355757ca7184e17674 Mon Sep 17 00:00:00 2001 From: rebortg Date: Fri, 11 Dec 2020 22:39:26 +0100 Subject: installation: fix lint errors --- docs/installation/virtual/libvirt.rst | 32 ++++++++++++++++++++------------ docs/installation/virtual/vmware.rst | 32 +++++++++++++++++++++++--------- 2 files changed, 43 insertions(+), 21 deletions(-) (limited to 'docs/installation/virtual') diff --git a/docs/installation/virtual/libvirt.rst b/docs/installation/virtual/libvirt.rst index 0d624b94..ff896d07 100644 --- a/docs/installation/virtual/libvirt.rst +++ b/docs/installation/virtual/libvirt.rst @@ -4,9 +4,10 @@ Running on Libvirt Qemu/KVM *************************** -Libvirt is an open-source API, daemon and management tool for managing platform virtualization. -There are several ways to deploy VyOS on libvirt kvm. Use Virt-manager and native CLI. -In an example we will be use use 4 gigabytes of memory, 2 cores CPU and default network virbr0. +Libvirt is an open-source API, daemon and management tool for managing platform +virtualization. There are several ways to deploy VyOS on libvirt kvm. +Use Virt-manager and native CLI. In an example we will be use use 4 gigabytes +of memory, 2 cores CPU and default network virbr0. CLI === @@ -14,8 +15,9 @@ CLI Deploy from ISO --------------- -Create VM name ``vyos_r1``. You must specify the path to the ``ISO`` image, the disk ``qcow2`` will be created automatically. -The ``default`` network is the virtual network (type Virtio) created by the hypervisor with NAT. +Create VM name ``vyos_r1``. You must specify the path to the ``ISO`` image, +the disk ``qcow2`` will be created automatically. The ``default`` network is +the virtual network (type Virtio) created by the hypervisor with NAT. .. code-block:: none @@ -46,11 +48,13 @@ Connect to VM with command ``virsh console vyos_r1`` vyos@vyos:~$ install image -After installation - exit from the console using the key combination ``Ctrl + ]`` and reboot the system. +After installation - exit from the console using the key combination +``Ctrl + ]`` and reboot the system. Deploy from qcow2 ----------------- -The convenience of using :abbr:`KVM (Kernel-based Virtual Machine)` images is that they don't need to be installed. +The convenience of using :abbr:`KVM (Kernel-based Virtual Machine)` +images is that they don't need to be installed. Download predefined VyOS.qcow2 image for ``KVM`` .. code-block:: none @@ -92,13 +96,15 @@ The system is fully operational. Virt-manager ============ -The virt-manager application is a desktop user interface for managing virtual machines through libvirt. -On the linux open :abbr:`VMM (Virtual Machine Manager)`. +The virt-manager application is a desktop user interface for managing virtual +machines through libvirt. On the linux open +:abbr:`VMM (Virtual Machine Manager)`. Deploy from ISO --------------- -1. Open :abbr:`VMM (Virtual Machine Manager)` and Create a new :abbr:`VM (Virtual Machine)` +1. Open :abbr:`VMM (Virtual Machine Manager)` and Create a new + :abbr:`VM (Virtual Machine)` 2. Choose ``Local install media`` (ISO) @@ -134,13 +140,15 @@ Download predefined VyOS.qcow2 image for ``KVM`` curl --url link_to_vyos_kvm.qcow2 --output /var/lib/libvirt/images/vyos_kvm.qcow2 -1. Open :abbr:`VMM (Virtual Machine Manager)` and Create a new :abbr:`VM (Virtual Machine)` +1. Open :abbr:`VMM (Virtual Machine Manager)` and Create a new + :abbr:`VM (Virtual Machine)` 2. Choose ``Import existing disk`` image .. figure:: /_static/images/virt-libvirt-qc-01.png -3. Choose the path to the image ``vyos_kvm.qcow2`` that was previously downloaded . Operation System can be any Debian based. +3. Choose the path to the image ``vyos_kvm.qcow2`` that was previously + downloaded . Operation System can be any Debian based. .. figure:: /_static/images/virt-libvirt-qc-02.png diff --git a/docs/installation/virtual/vmware.rst b/docs/installation/virtual/vmware.rst index c4299cbf..28614573 100644 --- a/docs/installation/virtual/vmware.rst +++ b/docs/installation/virtual/vmware.rst @@ -6,20 +6,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 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. +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. +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. @@ -28,5 +39,8 @@ It is advised that VyOS routers are configured in a resource group with adequate References ---------- +.. stop_vyoslinter + https://muralidba.blogspot.com/2018/03/how-does-linux-out-of-memory-oom-killer.html +.. start_vyoslinter \ No newline at end of file -- cgit v1.2.3