docs: update docs for v0.15 (#620)

* docs: update docs for v0.15 Signed-off-by: Pavel Tishkov <[email protected]> Co-authored-by: Lada Lysenko <[email protected]> Co-authored-by: Lada Lysenko <[email protected]> Co-authored-by: Ivan Mikheykin <[email protected]>
deckhouse · Jan 20, 2025 · 5a6670c · 5a6670c
1 parent 2b35450
commit 5a6670c
Show file tree

Hide file tree

Showing 14 changed files with 1,298 additions and 905 deletions.
diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md
@@ -5,7 +5,7 @@ weight: 40
 
 ## Introduction
 
-This guide is intended for [administrators](./README.md#role-model) of Deckhouse Virtualization Platform and describes how to create and modify cluster resources.
+This guide is intended for administrators of Deckhouse Virtualization Platform and describes how to create and modify cluster resources.
 
 The administrator also has rights to manage project resources, which are described in the [“User Guide”](./USER_GUIDE.md) document.
 
@@ -63,7 +63,11 @@ Check the result of the `ClusterVirtualImage` creation:
 d8 k get clustervirtualimage ubuntu-22.04
 # or shorter
 d8 k get cvi ubuntu-22.04
+```
+
+Example output:
 
+```txt
 # NAME           PHASE   CDROM   PROGRESS   AGE
 # ubuntu-22.04   Ready   false   100%       23h
 ```
@@ -83,7 +87,11 @@ You can trace the image creation process by adding the `-w` key to the previous
 
 ```bash
 d8 k get cvi ubuntu-22.04 -w
+```
 
+Example output:
+
+```txt
 # NAME           PHASE          CDROM   PROGRESS   AGE
 # ubuntu-22.04   Provisioning   false              4s
 # ubuntu-22.04   Provisioning   false   0.0%       4s
@@ -169,7 +177,11 @@ There are two options available for uploading from a cluster node and from an ar
 
 ```bash
 d8 k get cvi some-image -o jsonpath="{.status.imageUploadURLs}"  | jq
+```
 
+Example output:
+
+```txt
 # {
 #   "external":"https://virtualization.example.com/upload/g2OuLgRhdAWqlJsCMyNvcdt4o5ERIwmm",
 #   "inCluster":"http://10.222.165.239/upload"
@@ -192,6 +204,11 @@ After the upload is complete, the image should be created and enter the `Ready`
 
 ```bash
 d8 k get cvi some-image
+```
+
+Example output:
+
+```txt
 # NAME         PHASE   CDROM   PROGRESS   AGE
 # some-image   Ready   false   100%       1m
 ```
@@ -200,10 +217,43 @@ d8 k get cvi some-image
 
 The `VirtualMachineClass` resource is designed for centralized configuration of preferred virtual machine settings. It allows you to define CPU instructions and configuration policies for CPU and memory resources for virtual machines, as well as define ratios of these resources. In addition, `VirtualMachineClass` provides management of virtual machine placement across platform nodes. This allows administrators to effectively manage virtualization platform resources and optimally place virtual machines on platform nodes.
 
+The structure of the `VirtualMachineClass` resource is as follows:
+
+```yaml
+apiVersion: virtualization.deckhouse.io/v1alpha2
+kind: VirtualMachineClass
+metadata:
+  name: <vmclass-name>
+spec:
+  # The block describes the virtual processor parameters for virtual machines.
+  # This block cannot be changed after the resource has been created.
+  cpu: ...
+
+  # (optional) Describes the rules for node placement of virtual machines.
+  # When changed, it is automatically applied to all virtual machines using this VirtualMachineClass.
+  nodeSelector: ...
+
+  # (optional) Describes the sizing policy for configuring virtual machine resources.
+  # When changed, it is automatically applied to all virtual machines using this VirtualMachineClass.
+  sizingPolicies: ...
+```
+
+{{< alert level="warning" >}}
+Warning. Since changing the `.spec.nodeSelector` parameter affects all virtual machines using this `VirtualMachineClass`, the following should be considered:
+
+For Enterprise-edition: this may cause virtual machines to be migrated to new destination nodes if the current nodes do not meet placement requirements.
+For Community edition: this may cause virtual machines to restart according to the automatic change application policy set in the `.spec.disruptions.restartApprovalMode` parameter.
+{{< /alert >}}
+
 The virtualization platform provides 3 predefined `VirtualMachineClass` resources:
 
 ```bash
-kubectl get virtualmachineclass
+d8 k get virtualmachineclass
+```
+
+Example output:
+
+```txt
 NAME               PHASE   AGE
 host               Ready   6d1h
 host-passthrough   Ready   6d1h
@@ -226,8 +276,8 @@ spec:
   ...
 ```
 
-{{< alert level="warning" >}}
-Warning. It is recommended to create at least one `VirtualMachineClass` resource in the cluster with the Discovery type immediately after all nodes are configured and added to the cluster. This will allow the virtual machines to utilize a generic CPU with the highest possible CPU performance given the CPUs on the cluster nodes, allowing the virtual machines to utilize the maximum CPU capabilities and migrate seamlessly between cluster nodes if necessary.
+{{< alert level="info" >}}
+It is recommended to create at least one `VirtualMachineClass` resource in the cluster with the Discovery type immediately after all nodes are configured and added to the cluster. This will allow the virtual machines to utilize a generic CPU with the highest possible CPU performance given the CPUs on the cluster nodes, allowing the virtual machines to utilize the maximum CPU capabilities and migrate seamlessly between cluster nodes if necessary.
 {{< /alert >}}
 
 Platform administrators can create the required classes of virtual machines according to their needs, but it is recommended to create the minimum required. Consider the following example:
@@ -398,7 +448,7 @@ spec:
 - to create a vCPU of a specific CPU with a pre-defined instruction set, we use `type: Model`. In advance, to get a list of supported CPU names for the cluster node, run the command:
 
 ```bash
-kubectl get nodes <node-name> -o json | jq '.metadata.labels | to_entries[] | select(.key | test(“cpu-model”)) | .key | split(“/”)[1]'' -r
+d8 k get nodes <node-name> -o json | jq '.metadata.labels | to_entries[] | select(.key | test(“cpu-model”)) | .key | split(“/”)[1]'' -r
 
 # Sample output:
 #
@@ -436,33 +486,43 @@ The following is an example of migrating a selected virtual machine:
 Before starting the migration, see the current status of the virtual machine:
 
 ```bash
-kubectl get vm
+d8 k get vm
+```
+
+Example output:
+
+```txt
 # NAME                                   PHASE     NODE           IPADDRESS     AGE
 # linux-vm                              Running   virtlab-pt-1   10.66.10.14   79m
 ```
 
 We can see that it is currently running on the `virtlab-pt-1` node.
 
-To migrate a virtual machine from one host to another, taking into account the virtual machine placement requirements, the `VirtualMachineOperations` (`vmop`) resource with the migrate type is used.
+To migrate a virtual machine from one host to another, taking into account the virtual machine placement requirements, the `VirtualMachineOperation` (`vmop`) resource with the `Evict` type is used.
 
 ```yaml
-d8 k apply -f - <<EOF
+d8 k create -f - <<EOF
 apiVersion: virtualization.deckhouse.io/v1alpha2
 kind: VirtualMachineOperation
 metadata:
-  name: migrate-linux-vm-$(date +%s)
+  generateName: evict-linux-vm-
 spec:
   # virtual machine name
   virtualMachineName: linux-vm
   # operation for migration
-  type: Migrate
+  type: Evict
 EOF
 ```
 
 Immediately after creating the `vmop` resource, run the command:
 
 ```bash
-kubectl get vm -w
+d8 k get vm -w
+```
+
+Example output:
+
+```txt
 # NAME                                   PHASE       NODE           IPADDRESS     AGE
 # linux-vm                              Running     virtlab-pt-1   10.66.10.14   79m
 # linux-vm                              Migrating   virtlab-pt-1   10.66.10.14   79m
@@ -477,21 +537,21 @@ When performing work on nodes with running virtual machines, there is a risk of
 To do this, run the following command:
 
 ```bash
-kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-dat
+d8 k drain <nodename> --ignore-daemonsets --delete-emptydir-dat
 ```
 
 where `<nodename>` is the node on which the work is to be performed and which should be freed from all resources (including system resources).
 
 If there is a need to push only virtual machines off the node, run the following command:
 
 ```bash
-kubectl drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data
+d8 k drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data
 ```
 
-After running the `kubectl drain` conmade, the node will go into maintenance mode and no virtual machines will be able to start on it. To take it out of maintenance mode, run the following command:
+After running the `d8 k drain` command, the node will go into maintenance mode and no virtual machines will be able to start on it. To take it out of maintenance mode, run the following command:
 
 ```bash
-kubectl uncordon <nodename>
+d8 k uncordon <nodename>
 ```
 
 ![](./images/drain.png)
@@ -523,7 +583,7 @@ For storing disks (`VirtualDisk`) and images (`VirtualImage`) with the `Persiste
 The list of storage supported by the platform can be listed by executing the command to view storage classes (`StorageClass`)
 
 ```bash
-kubectl get storageclass
+d8 k get storageclass
 ```
 
 Example of command execution: