docs: update docs due v0.18.0 (#992)

 Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
Co-authored-by: Denis Rebenok <60424108+denmaloyreb@users.noreply.github.com>

Author: fl64

docs/ADMIN_GUIDE.md

@@ -119,6 +119,29 @@ Where:
 - `allowedStorageClassNames` (optional): A list of the allowed StorageClass for creating a VirtualDisk that can be explicitly specified in the resource specification.
 - `defaultStorageClassName` (optional): The StorageClass used by default when creating a VirtualDisk if the `.spec.persistentVolumeClaim.storageClassName` parameter is not specified.
 
+**Security Event Audit**
+
+{{< alert level="warning">}}
+Not available in CE edition.
+{{{< /alert >}}
+
+{{{< alert level="warning">}}
+To set up auditing, the following modules must be enabled:
+
+- `log-shipper`,
+- `runtime-audit-engine`.
+{{{< /alert >}}
+
+To enable security event auditing, set the module’s `.spec.settings.audit.enabled` parameter to` true`:
+
+```yaml
+spec:
+  enabled: true
+  settings:
+    audit:
+      enabled: true
+```
+
 {{< alert level="info" >}}
 For a complete list of configuration options, see [Configuration](./configuration.html).
 {{< /alert >}}
@@ -202,7 +225,7 @@ In this example, let's create a cluster image.
 
    ```bash
    d8 k get clustervirtualimage ubuntu-22-04
-   
+
    # A short version of the command.
    d8 k get cvi ubuntu-22-04
    ```
@@ -541,6 +564,57 @@ Changes in the `.spec.sizingPolicy` block can also affect virtual machines. For
 When configuring `sizingPolicy`, be sure to consider the [CPU topology](./user_guide.html#automatic-cpu-topology-configuration) for virtual machines.
 {{< /alert >}}
 
+The `cores` block is mandatory and specifies the range of cores to which the rule described in the same block applies.
+
+The ranges [min; max] for the cores parameter must be strictly sequential and non-overlapping.
+
+Correct structure (the ranges follow one another without intersections):
+
+```yaml
+- cores:
+    min: 1
+    max: 4...
+
+- cores:
+    min: 5   # Start of next range = (previous max + 1)
+    max: 8
+```
+
+Invalid option (overlapping values):
+
+```yaml
+- cores:
+    min: 1
+    max: 4...
+
+- cores:
+    min: 4   # Error: Value 4 is already included in the previous range
+    max: 8
+```
+
+{{< alert level = "warning" >}}
+Rule: Each new range must start with a value that immediately follows the max of the previous range.
+{{< /alert >}}
+
+Additional requirements can be specified for each range of cores:
+
+1. Memory — specify:
+
+    - Either minimum and maximum memory for all cores in the range,
+    - Either the minimum and maximum memory per core (`memoryPerCore`).
+
+2. Allowed fractions of cores (`coreFractions`) — a list of allowed values (for example, [25, 50, 100] for 25%, 50%, or 100% core usage).
+
+{{< alert level = "warning" >}}
+Important: For each range of cores, be sure to specify:
+
+- Either memory (or `memoryPerCore`),
+- Either coreFractions,
+- Or both parameters at the same time.
+{{< /alert >}}
+
+Here is an example of a policy with similar settings:
+
 ```yaml
 spec:
   sizingPolicies:

docs/ADMIN_GUIDE.ru.md

@@ -119,6 +119,29 @@ spec:
 - `allowedStorageClassNames` (опционально) — это список допустимых StorageClass для создания VirtualDisk, которые можно явно указать в спецификации ресурса;
 - `defaultStorageClassName` (опционально) — это StorageClass, используемый по умолчанию при создании VirtualDisk, если параметр `.spec.persistentVolumeClaim.storageClassName` не задан.
 
+**Аудит событий безопасности**
+
+{{< alert level="warning" >}}
+Недоступно в CE-редакции.
+{{< /alert >}}
+
+{{< alert level="warning" >}}
+Для активации аудита требуется, чтобы были включены следующие модули:
+
+- `log-shipper`,
+- `runtime-audit-engine`.
+{{< /alert >}}
+
+Чтобы включить аудит событий безопасности, установите параметр `.spec.settings.audit.enabled` настроек модуля  в `true`:
+
+```yaml
+spec:
+  enabled: true
+  settings:
+    audit:
+      enabled: true
+```
+
 {{< alert level="info" >}}
 Полный перечень параметров конфигурации приведен в разделе [Настройки](./configuration.html).
 {{< /alert >}}
@@ -206,7 +229,7 @@ spec:
 
    ```bash
    d8 k get clustervirtualimage ubuntu-22-04
-   
+
    # Короткий вариант команды.
    d8 k get cvi ubuntu-22-04
    ```
@@ -555,6 +578,57 @@ spec:
 При настройке `sizingPolicy` будьте внимательны и учитывайте [топологию CPU](./user_guide.html#автоматическая-конфигурация-топологии-cpu) для виртуальных машин.
 {{< /alert >}}
 
+Блок `cores` обязательный и задает диапазоны ядер, на которые распространяется правило, описанное в этом же блоке.
+
+Диапазоны [min; max] для параметра `cores` должны быть строго последовательными и непересекающимися.
+
+Правильная структура (диапазоны идут друг за другом без пересечений):
+
+```yaml
+- cores:
+    min: 1
+    max: 4
+    ...
+- cores:
+    min: 5   # Начало следующего диапазона = (предыдущий max + 1)
+    max: 8
+```
+
+Недопустимый вариант (пересечение значений):
+
+```yaml
+- cores:
+    min: 1
+    max: 4
+    ...
+- cores:
+    min: 4   # Ошибка: Значение 4 уже входит в предыдущий диапазон
+    max: 8
+```
+
+{{< alert level="warning" >}}
+Правило : Каждый новый диапазон должен начинаться со значения, непосредственно следующего за max предыдущего диапазона.
+{{< /alert >}}
+
+Для каждого диапазона ядер `cores` можно задать дополнительные требования:
+
+1. Память (`memory`) — указывается:
+
+    - Либо минимум и максимум памяти для всех ядер в диапазоне,
+    - Либо минимум и максимум памяти на одно ядро (`memoryPerCore`).
+
+2. Допустимые доли ядер (`coreFractions`) — список разрешенных значений (например, [25, 50, 100] для 25%, 50% или 100% использования ядра).
+
+{{< alert level="warning" >}}
+Важно : Для каждого диапазона cores обязательно укажите:
+
+- Либо memory (или `memoryPerCore`),
+- Либо coreFractions,
+- Либо оба параметра одновременно.
+{{< /alert >}}
+
+Пример политики с подобными настройками:
+
 ```yaml
 spec:
   sizingPolicies:
@@ -569,7 +643,6 @@ spec:
         min: 1Gi
         max: 8Gi
         step: 512Mi
-      dedicatedCores: [false]
       coreFractions: [5, 10, 20, 50, 100]
     # Для диапазона от 5 до 8 ядер возможно использовать от 5 до 16 ГБ оперативной памяти с шагом 1 ГБ,
     # т.е. 5 ГБ, 6 ГБ, 7 ГБ и т. д.
@@ -582,7 +655,6 @@ spec:
         min: 5Gi
         max: 16Gi
         step: 1Gi
-      dedicatedCores: [false]
       coreFractions: [20, 50, 100]
     # Для диапазона от 9 до 16 ядер возможно использовать от 9 до 32 ГБ оперативной памяти с шагом 1 ГБ.
     # При необходимости можно использовать выделенные ядра.
@@ -594,7 +666,6 @@ spec:
         min: 9Gi
         max: 32Gi
         step: 1Gi
-      dedicatedCores: [true, false]
       coreFractions: [50, 100]
     # Для диапазона от 17 до 248 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчёта на одно ядро.
     # Доступны для использования только выделенные ядра.
@@ -606,7 +677,6 @@ spec:
         perCore:
           min: 1Gi
           max: 2Gi
-      dedicatedCores: [true]
       coreFractions: [100]
 ```
 

docs/INSTALL.md

@@ -122,6 +122,7 @@ For Windows family operating systems, the platform supports initialization with
 
 - Maximum number of cores supported: `248`.
 - Maximum amount of RAM: `1024 GB`.
+- The maximum number of block devices to be attached: `16`.
 
 ## Supported storage systems
 

docs/INSTALL.ru.md

@@ -126,6 +126,7 @@ weight: 15
 
 - Максимальное число поддерживаемых ядер: `248`.
 - Максимальный объем оперативной памяти: `1024 ГБ`.
+- Максимальное количество подключаемых блочных устройств: `16`.
 
 ## Поддерживаемые хранилища
 

docs/USER_GUIDE.md

@@ -1619,6 +1619,34 @@ The live migration process involves several steps:
 Network speed plays an important role. If bandwidth is low, there are more iterations and VM downtime can increase. In the worst case, the migration may not complete at all.
 {{{< /alert >}}
 
+#### AutoConverge mechanism
+
+If the network struggles to handle data transfer and the number of "dirty" pages keeps growing, the AutoConverge mechanism can be useful. It helps complete migration even with low network bandwidth.
+
+The working principles of AutoConverge mechanism:
+
+1. **VM CPU slowdown**.
+
+    The hypervisor gradually reduces the CPU frequency of the source VM. This reduces the rate at which new "dirty" pages appear. The higher the load on the VM, the greater the slowdown.
+
+2. **Synchronization acceleration**.
+
+    Once the data transfer rate exceeds the memory change rate, final synchronization is started and the VM switches to the new node.
+
+3. **Automatic Termination**
+
+    Final synchronization is started when the data transfer rate exceeds the memory change rate.
+
+AutoConverge is a kind of "insurance" that ensures that the migration completes even if the network struggles to handle data transfer. However, CPU slowdown can affect the performance of applications running on the VM, so its use should be monitored.
+
+#### Configuring Migration Policy
+
+To configure migration behavior, use the  `.spec.liveMigrationPolicy` parameter in the VM configuration. The following options are available:
+
+- `AlwaysSafe` - Migration is performed without slowing down the CPU (AutoConverge is not used). Suitable for cases where maximizing VM performance is important but requires high network bandwidth.
+- `PreferSafe` - (used as the default policy) By default, migration runs without AutoConverge, but CPU slowdown can be enabled manually if the migration fails to complete. This is done by using the VirtualMachineOperation resource with `type=Evict` and `force=true`.
+- `AlwaysForced` - Migration always uses AutoConverge, meaning the CPU is slowed down when necessary. This ensures that the migration completes even if the network is bad, but may degrade VM performance.
+- `PreferForced` - By default migration goes with AutoConverge, but slowdown can be manually disabled via VirtualMachineOperation with the parameter `type=Evict` and `force=false`.
 
 #### Migration Types
 

docs/USER_GUIDE.ru.md

@@ -1626,6 +1626,35 @@ EOF
 Cкорость сети играет важную роль. Если пропускная способность низкая, итераций становится больше, а время простоя ВМ может увеличиться. В худшем случае миграция может вообще не завершиться.
 {{< /alert >}}
 
+#### Механизм AutoConverge
+
+Если сеть не справляется с передачей данных, а количество «грязных» страниц продолжает расти, будет полезен механизм AutoConverge. Он помогает завершить миграцию даже при низкой пропускной способности сети.
+
+Принципы работы механизма AutoConverge:
+
+1. **Замедление процессора ВМ**
+
+    Гипервизор постепенно снижает частоту процессора исходной ВМ. Это уменьшает скорость появления новых «грязных» страниц. Чем выше нагрузка на ВМ, тем сильнее замедление.
+
+2. **Ускорение синхронизации**
+
+    Как только скорость передачи данных превышает скорость изменения памяти, запускается финальная синхронизация, и ВМ переключается на новый узел.
+
+3. **Автоматическое завершение**
+
+    Финальная синхронизация запускается, когда скорость передачи данных превышает скорость изменения памяти.
+
+AutoConverge — это своего рода «страховка», которая гарантирует, что миграция завершится, даже если сеть не справляется с передачей данных. Однако замедление процессора может повлиять на производительность приложений, работающих на ВМ, поэтому его использование нужно контролировать.
+
+#### Настройка политики миграции
+
+Для настройки поведения миграции используйте параметр `.spec.liveMigrationPolicy` в конфигурации ВМ. Допустимые значения параметра:
+
+- `AlwaysSafe` — Миграция всегда выполняется без замедления процессора (AutoConverge не используется). Подходит для случаев, когда важна максимальная производительность ВМ, но требует высокой пропускной способности сети.
+- `PreferSafe` — (используется в качестве политики по умолчанию) Миграция выполняется без замедления процессора (AutoConverge не используется). Однако можно запустить миграцию с замедлением процессора, используя ресурс VirtualMachineOperation с параметрами `type=Evict` и `force=true`.
+- `AlwaysForced` — Миграция всегда использует AutoConverge, то есть процессор замедляется при необходимости. Это гарантирует завершение миграции даже при плохой сети, но может снизить производительность ВМ.
+- `PreferForced` — Миграция использует AutoConverge, то есть процессор замедляется при необходимости.  Однако можно запустить миграцию без замедления процессора, используя ресурс VirtualMachineOperation с параметрами `type=Evict` и `force=false`.
+
 #### Виды миграции
 
 Миграция может осуществляться пользователем вручную, либо автоматически при следующих системных событиях: