Skip to content

Commit 8ee20e3

Browse files
fl64Roman Sysoev
authored and
Roman Sysoev
committed
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]>
1 parent c971858 commit 8ee20e3

14 files changed

+1298
-905
lines changed

docs/ADMIN_GUIDE.md

+76-16
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ weight: 40
55

66
## Introduction
77

8-
This guide is intended for [administrators](./README.md#role-model) of Deckhouse Virtualization Platform and describes how to create and modify cluster resources.
8+
This guide is intended for administrators of Deckhouse Virtualization Platform and describes how to create and modify cluster resources.
99

1010
The administrator also has rights to manage project resources, which are described in the [“User Guide”](./USER_GUIDE.md) document.
1111

@@ -63,7 +63,11 @@ Check the result of the `ClusterVirtualImage` creation:
6363
d8 k get clustervirtualimage ubuntu-22.04
6464
# or shorter
6565
d8 k get cvi ubuntu-22.04
66+
```
67+
68+
Example output:
6669

70+
```txt
6771
# NAME PHASE CDROM PROGRESS AGE
6872
# ubuntu-22.04 Ready false 100% 23h
6973
```
@@ -83,7 +87,11 @@ You can trace the image creation process by adding the `-w` key to the previous
8387

8488
```bash
8589
d8 k get cvi ubuntu-22.04 -w
90+
```
8691

92+
Example output:
93+
94+
```txt
8795
# NAME PHASE CDROM PROGRESS AGE
8896
# ubuntu-22.04 Provisioning false 4s
8997
# 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
169177

170178
```bash
171179
d8 k get cvi some-image -o jsonpath="{.status.imageUploadURLs}" | jq
180+
```
172181

182+
Example output:
183+
184+
```txt
173185
# {
174186
# "external":"https://virtualization.example.com/upload/g2OuLgRhdAWqlJsCMyNvcdt4o5ERIwmm",
175187
# "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`
192204

193205
```bash
194206
d8 k get cvi some-image
207+
```
208+
209+
Example output:
210+
211+
```txt
195212
# NAME PHASE CDROM PROGRESS AGE
196213
# some-image Ready false 100% 1m
197214
```
@@ -200,10 +217,43 @@ d8 k get cvi some-image
200217

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

220+
The structure of the `VirtualMachineClass` resource is as follows:
221+
222+
```yaml
223+
apiVersion: virtualization.deckhouse.io/v1alpha2
224+
kind: VirtualMachineClass
225+
metadata:
226+
name: <vmclass-name>
227+
spec:
228+
# The block describes the virtual processor parameters for virtual machines.
229+
# This block cannot be changed after the resource has been created.
230+
cpu: ...
231+
232+
# (optional) Describes the rules for node placement of virtual machines.
233+
# When changed, it is automatically applied to all virtual machines using this VirtualMachineClass.
234+
nodeSelector: ...
235+
236+
# (optional) Describes the sizing policy for configuring virtual machine resources.
237+
# When changed, it is automatically applied to all virtual machines using this VirtualMachineClass.
238+
sizingPolicies: ...
239+
```
240+
241+
{{< alert level="warning" >}}
242+
Warning. Since changing the `.spec.nodeSelector` parameter affects all virtual machines using this `VirtualMachineClass`, the following should be considered:
243+
244+
For Enterprise-edition: this may cause virtual machines to be migrated to new destination nodes if the current nodes do not meet placement requirements.
245+
For Community edition: this may cause virtual machines to restart according to the automatic change application policy set in the `.spec.disruptions.restartApprovalMode` parameter.
246+
{{< /alert >}}
247+
203248
The virtualization platform provides 3 predefined `VirtualMachineClass` resources:
204249

205250
```bash
206-
kubectl get virtualmachineclass
251+
d8 k get virtualmachineclass
252+
```
253+
254+
Example output:
255+
256+
```txt
207257
NAME PHASE AGE
208258
host Ready 6d1h
209259
host-passthrough Ready 6d1h
@@ -226,8 +276,8 @@ spec:
226276
...
227277
```
228278

229-
{{< alert level="warning" >}}
230-
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.
279+
{{< alert level="info" >}}
280+
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.
231281
{{< /alert >}}
232282

233283
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:
398448
- 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:
399449

400450
```bash
401-
kubectl get nodes <node-name> -o json | jq '.metadata.labels | to_entries[] | select(.key | test(“cpu-model”)) | .key | split(“/”)[1]'' -r
451+
d8 k get nodes <node-name> -o json | jq '.metadata.labels | to_entries[] | select(.key | test(“cpu-model”)) | .key | split(“/”)[1]'' -r
402452
403453
# Sample output:
404454
#
@@ -436,33 +486,43 @@ The following is an example of migrating a selected virtual machine:
436486
Before starting the migration, see the current status of the virtual machine:
437487

438488
```bash
439-
kubectl get vm
489+
d8 k get vm
490+
```
491+
492+
Example output:
493+
494+
```txt
440495
# NAME PHASE NODE IPADDRESS AGE
441496
# linux-vm Running virtlab-pt-1 10.66.10.14 79m
442497
```
443498

444499
We can see that it is currently running on the `virtlab-pt-1` node.
445500

446-
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.
501+
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.
447502

448503
```yaml
449-
d8 k apply -f - <<EOF
504+
d8 k create -f - <<EOF
450505
apiVersion: virtualization.deckhouse.io/v1alpha2
451506
kind: VirtualMachineOperation
452507
metadata:
453-
name: migrate-linux-vm-$(date +%s)
508+
generateName: evict-linux-vm-
454509
spec:
455510
# virtual machine name
456511
virtualMachineName: linux-vm
457512
# operation for migration
458-
type: Migrate
513+
type: Evict
459514
EOF
460515
```
461516

462517
Immediately after creating the `vmop` resource, run the command:
463518

464519
```bash
465-
kubectl get vm -w
520+
d8 k get vm -w
521+
```
522+
523+
Example output:
524+
525+
```txt
466526
# NAME PHASE NODE IPADDRESS AGE
467527
# linux-vm Running virtlab-pt-1 10.66.10.14 79m
468528
# 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
477537
To do this, run the following command:
478538

479539
```bash
480-
kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-dat
540+
d8 k drain <nodename> --ignore-daemonsets --delete-emptydir-dat
481541
```
482542

483543
where `<nodename>` is the node on which the work is to be performed and which should be freed from all resources (including system resources).
484544

485545
If there is a need to push only virtual machines off the node, run the following command:
486546

487547
```bash
488-
kubectl drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data
548+
d8 k drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data
489549
```
490550

491-
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:
551+
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:
492552

493553
```bash
494-
kubectl uncordon <nodename>
554+
d8 k uncordon <nodename>
495555
```
496556

497557
![](./images/drain.png)
@@ -523,7 +583,7 @@ For storing disks (`VirtualDisk`) and images (`VirtualImage`) with the `Persiste
523583
The list of storage supported by the platform can be listed by executing the command to view storage classes (`StorageClass`)
524584

525585
```bash
526-
kubectl get storageclass
586+
d8 k get storageclass
527587
```
528588

529589
Example of command execution:

0 commit comments

Comments
 (0)