From ff917a0a4b8315ecd082d6715bb4405e1dc7f895 Mon Sep 17 00:00:00 2001 From: Benjamin Affolter <5555767+bliemli@users.noreply.github.com> Date: Sun, 29 Sep 2024 14:54:39 +0200 Subject: [PATCH] Proofread instance types and preferences chapter --- .../instance-types-and-preferences/_index.md | 16 +-- .../common-instancetypes.md | 128 +++++++++++------- .../create-instancetype.md | 32 +++-- .../reassign-instancetype.md | 47 ++++--- .../types-introduction.md | 33 +++-- 5 files changed, 149 insertions(+), 107 deletions(-) diff --git a/content/en/docs/instance-types-and-preferences/_index.md b/content/en/docs/instance-types-and-preferences/_index.md index 861a15d..4c6c7d4 100644 --- a/content/en/docs/instance-types-and-preferences/_index.md +++ b/content/en/docs/instance-types-and-preferences/_index.md @@ -1,19 +1,19 @@ --- -title: "Instance Types and Preferences" +title: "Instance types and preferences" weight: 3 labfoldernumber: "03" description: > - Learn how to use and define Instance Types and Preferences. + Learn how to use and define instance types and preferences --- -In this section we will see how we can define Instance Types and Preferences. These provide a way to define a set of +In this section we will see how we can define instance types and preferences. These provide a way to define a set of runtime characteristics like resources or performance settings which can then be reused. -## Lab Goals +## Lab goals * Know the benefit of `VirtualMachineInstancetype` and `VirtualMachinePreference` -* Examine Common Instance types and Preferences. -* Deploy VMs with a common Instance type. -* Define your own Instance type and Preference settings. -* Use your custom Instance types with your VMs. +* Examine common instance types and preferences +* Deploy VMs with a common instance type +* Define your own instance type and preference settings +* Use your custom instance types with your VMs diff --git a/content/en/docs/instance-types-and-preferences/common-instancetypes.md b/content/en/docs/instance-types-and-preferences/common-instancetypes.md index 33f08bb..3c55f9f 100644 --- a/content/en/docs/instance-types-and-preferences/common-instancetypes.md +++ b/content/en/docs/instance-types-and-preferences/common-instancetypes.md @@ -1,28 +1,32 @@ --- -title: "Common types and preferences" +title: "Common instance types and preferences" weight: 32 labfoldernumber: "03" description: > - Discover and use common Instancetypes and Preferences provided by KubeVirt. + Discover and use common instance types and preferences provided by KubeVirt --- -The KubeVirt project [Common Instancetypes and Preferences](https://github.com/kubevirt/common-instancetypes) provides a set of Instancetypes and Preferences. +The KubeVirt project provides a set of [common instance types and preferences](https://github.com/kubevirt/common-instancetypes). +In this lab, we are going to have a look at these and how they can help us create virtual machines. -## Deployment of Common Instancetypes and Preferences +## Deployment of common instance types and preferences -The common Instancetypes and Preferences are not available by default. They have to be deployed manually or using a feature gate of the KubeVirt operator. +The common instance types and preferences are not available by default. They have to be deployed manually or by using one of the KubeVirt Operator's feature gates. You can check the configuration on the KubeVirt CustomResource: + ```bash kubectl get kubevirt kubevirt --namespace=kubevirt -o jsonpath={.spec.configuration.developerConfiguration.featureGates} ``` or + ```bash kubectl get kubevirt kubevirt --namespace=kubevirt -o yaml ``` The relevant section on the CustomResource is the following: + ```yaml apiVersion: kubevirt.io/v1 kind: KubeVirt @@ -36,26 +40,28 @@ spec: [...] ``` -With the feature gate enabled, the operator itself takes care of deploying the cluster wide common Instancetypes and Preferences. +With the feature gate enabled, the Operator itself takes care of deploying the cluster wide common instance types and preferences. -### Manually deploy the Common Instancetypes and Preferences +### Manually deploy the common instance types and preferences -This step has been done for your on the Lab cluster. -How to deploy the Common Instancetypes and Preferences on your own cluster can be found in the [documentation](https://kubevirt.io/user-guide/user_workloads/deploy_common_instancetypes/). +This step has been done for your on the lab cluster. +How to deploy the common instance types and preferences on your own cluster can be found in the [documentation](https://kubevirt.io/user-guide/user_workloads/deploy_common_instancetypes/). -## List and inspect Instancetypes +## List and inspect instance types -Be aware that the common instancetypes and preferences are cluster wide. Therefore, the CustomResources are +Be aware that the common instance types and preferences are cluster-wide resources. They are called `VirtualMachineClusterInstancetype` and `VirtualMachineClusterPreference`. You can list the available instance types using: + ```bash kubectl get virtualmachineclusterinstancetype ``` -Shortened output of the command above: +A shortened output of the command above: + ```bash NAME AGE cx1.2xlarge 10m @@ -79,7 +85,7 @@ u1.small 10m u1.xlarge 10m ``` -As you see the instancetypes follow the naming schema: +As you see the instance types follow a specific naming schema: ```bash instanceTypeName = seriesName , "." , size; @@ -100,19 +106,21 @@ The class `u`, `o`, `cx`, `g`, `m`, `n` and `rt` mean the following: * **O** (overcommitted) - Based on `u` with the only difference that memory will be overcommitted. Allows higher workload density. * **CX** (compute exclusive) - Provides exclusive compute resources for compute intensive applications. * **GN** (gpu nvidia) - Instance type for VMs which consume attached NVIDIA GPUs. -* **M** (memory) - Provides resources for memory intensive applications. -* **N** (network) - Provide resources for network intensive DPDK[^1] applications like Virtual Network Functions. -* **RT** (realtime) - Provide resources for realtime intensive applications. +* **M** (memory) - Provides resources for memory-intensive applications. +* **N** (network) - Provide resources for network-intensive DPDK[^1] applications like Virtual Network Functions (VNF). +* **RT** (realtime) - Provide resources for realtime-intensive applications. We therefore can say that the classes `u` and `o` are agnostic to the workload. The other classes are optimized for specific workload. -You may see the details of an instancetype by describing the resource +You may see the details of an instance type by describing the resource: + ```bash kubectl describe virtualmachineclusterinstancetype o1.nano ``` -As an example you'll see that the instancetype `o1.nano` has 1 CPU, 512Mi of memory and overcommittes memory by 50%. The following output is shortened: +As an example you will see that the instance type `o1.nano` has 1 CPU, 512Mi memory and overcommits memory by 50%. The following output is shortened: + ``` Name: o1.nano Namespace: @@ -143,13 +151,14 @@ Spec: ``` -## List and inspect Preferences +## List and inspect preferences ```bash kubectl get virtualmachineclusterpreference ``` -Shortened output of the command above: +A shortened output of the command above: + ``` NAME AGE alpine 10m @@ -158,11 +167,12 @@ centos.7 10m ``` You may see the details of a preference by describing the resource: + ```bash kubectl describe virtualmachineclusterpreference cirros ``` -As an example you'll see that the instancetype `cirros` has the requirements of 1 CPU, 256Mi memory. The following output is shortened: +As an example you'll see that the instance type `cirros` has the requirements of 1 CPU, 256Mi memory. The following output is shortened: ``` Name: cirros @@ -191,14 +201,15 @@ Spec: ``` -## Querying for specific instancetypes and preferences with labels +## Querying for specific instance types and preferences with labels ### Instancetypes -These instancetypes are labeled according to their specification. You can use labels to find the correct instancetype. +These instance types are labeled according to their specification. You can use labels to find the correct instance type. + +Instance types are known to use the following labels: -Instancetypes are known to use the following labels: ```properties instancetype.kubevirt.io/common-instancetypes-version: The version of the common-instancetypes project used to generate these resources. instancetype.kubevirt.io/vendor: The vendor of the resource, this is always kubevirt.io upstream and should be changed by downstream vendors consuming the project. @@ -215,12 +226,14 @@ instancetype.kubevirt.io/hugepages: If hugepages are requested by the instance t instancetype.kubevirt.io/gpus: If GPUs are requested by the instance type. ``` -As an example you can query for 4 CPUs: +As an example, you can query for 4 CPUs: + ```bash kubectl get virtualmachineclusterinstancetype --selector instancetype.kubevirt.io/cpu=4 ``` -Output will list all instancetypes with 4 CPUs: +Output will list all instance types with 4 CPUs: + ``` NAME AGE cx1.xlarge 10m @@ -235,7 +248,8 @@ u1.xlarge 10m ### Preferences -Just like instancetypes the preferences are labeled with the following labels: +Just like instance types, preferences are labeled with the following labels: + ```properties instancetype.kubevirt.io/common-instancetypes-version: The version of the common-instancetypes project used to generate these resources. instancetype.kubevirt.io/vendor: The vendor of the resource, this is always kubevirt.io upstream and should be changed by downstream vendors consuming the project. @@ -246,11 +260,13 @@ instancetype.kubevirt.io/arch: The underlying architecture of the workload suppo ``` We can use these labels to query preferences: + ```bash kubectl get virtualmachineclusterpreference --selector instancetype.kubevirt.io/os-type=linux ``` -Output will list all preferences targeting the operating system linux (output shortened): +The output will list all preferences targeting the operating system linux (output shortened): + ``` NAME AGE alpine 10m @@ -265,10 +281,10 @@ ubuntu 10m ``` -## {{% task %}} Find matching Instancetype and preference +## {{% task %}} Find matching instance type and preference -You want to find the optimal configuration of instancetype and preference for a Windows 10 64-bit installation. -According to Microsoft the Windows 10 system requirements[^2] are the following: +You want to find the optimal configuration of instance type and preference for a Windows 10 64-bit virtual machine. +According to Microsoft, the Windows 10 system requirements[^2] are the following: ``` Processor: 1 gigahertz (GHz) or faster processor or SoC @@ -276,16 +292,18 @@ RAM: 2 GB for 64-bit Hard disk space: 20 GB for 64-bit OS ``` -Try to find the best matching instancetype and preference for a Windows 10 minimal installation using label selectors. +Try to find the best matching instance type and preference for a Windows 10 minimal installation using label selectors. {{% details title="Task Hint" %}} You can query instance types as follows: + ```bash kubectl get virtualmachineclusterinstancetype \ --selector instancetype.kubevirt.io/cpu=1,instancetype.kubevirt.io/memory=2Gi ``` -Will return something like: +Above query will return something like: + ```bash NAME AGE cx1.medium 10m @@ -293,14 +311,16 @@ o1.small 10m u1.small 10m ``` -You would most likely pick `o1.small` or `u1.small` as your instancetype. - +You would most likely pick `o1.small` or `u1.small` as your instance type. For preferences, you can use the following query: + ```bash kubectl get virtualmachineclusterpreference --selector instancetype.kubevirt.io/os-type=windows ``` +Which outputs: + ``` NAME AGE windows.10 10m @@ -317,7 +337,7 @@ windows.2k22 10m windows.2k22.virtio 10m ``` -The preferences `windows.10` or `windows.10.virtio` are the best matching. +The preferences `windows.10` or `windows.10.virtio` are the best-matching. {{% alert title="Note" color="info" %}} This only fulfills the machines minimal requirements. In a production environment you would most likely size your instance bigger than the minimal requirements. @@ -330,10 +350,10 @@ This only fulfills the machines minimal requirements. In a production environmen Deploy two VMs with different instance types: -* Deploy a cirros VM using an `u` class instancetype and a matching preference. +* Deploy a cirros VM using a `u` class instance type and a matching preference * Write the VM specification in `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` -* Deploy a cirros VM using an `o` class instancetype and the same preference. - * rite the VM specification in `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` +* Deploy a cirros VM using a `o` class instance type and the same preference + * Write the VM specification in `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` {{% onlyWhen tolerations %}} @@ -345,6 +365,7 @@ Don't forget the `tolerations` from the setup chapter to make sure the VM will b {{% details title="Solution" %}} `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` specification: + ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine @@ -390,6 +411,7 @@ spec: ``` `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` specification: + ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine @@ -434,8 +456,7 @@ spec: userDataBase64: SGkuXG4= ``` - -Apply and start both VMs with +Apply and start both VMs using: ```bash kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml --namespace=$USER @@ -446,26 +467,29 @@ virtctl start {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}- {{% /details %}} -## {{% task %}} Inspect difference due to instancetype +## {{% task %}} Instance type differences -The main difference in the instancetypes `u` and `o` are memory overcommitting. Let's inspect our two VMs. What exactly means -overcommitting in the scope of a VirtualMachine instances? Overcommitting means we assign the VM more memory as we request +The main difference in the instance types `u` and `o` are memory overcommitting. Let's inspect our two VMs. What exactly means +overcommitting in the scope of a VirtualMachine instance? Overcommitting means that we assign more memory to a VM than we requested from the cluster by setting `spec.domain.memory.guest` to a higher value than `spec.domain.resources.requests.memory`. What would you expect from both VMs? -{{% details title="Task Hint" %}} -* `u` class should have equal request for `spec.domain.memory.guest` and `spec.domain.resources.requests.memory` -* `o` class should have higher request for `spec.domain.memory.guest` as `spec.domain.resources.requests.memory` +{{% details title="Task hint" %}} + +* `u` class should have equal requests for `spec.domain.memory.guest` and `spec.domain.resources.requests.memory` +* `o` class should have higher requests for `spec.domain.memory.guest` than `spec.domain.resources.requests.memory` -For both VMs we would expect the guest os to have approximately 512 mb of ram. +For both VMs we would expect the guest OS to have approximately 512Mi of memory. {{% /details %}} Check the expectations about memory settings of both VirtualMachine instances `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros` and `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros`. Do they match our expectations? -{{% details title="Task Hint" %}} +{{% details title="Task hint" %}} + Describe both VirtualMachine instances using: + ```bash kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml --namespace=$USER kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml --namespace=$USER @@ -488,7 +512,7 @@ spec: [...] ``` -`o1-cirros` instance: +The `o1-cirros` instance: ```yaml apiVersion: kubevirt.io/v1 @@ -505,7 +529,7 @@ spec: [...] ``` -As we can see in the difference between `spec.domain.memory.guest` and `spec.domain.resources.requests.memory` the `o` class actually overcommits by 50% as defined in the `o1.nano` instance type: +As we can see in the difference between `spec.domain.memory.guest` and `spec.domain.resources.requests.memory`, the `o` class actually overcommits by 50% as defined in the `o1.nano` instance type: ```yaml apiVersion: instancetype.kubevirt.io/v1beta1 @@ -521,7 +545,7 @@ spec: [...] ``` -The `.status.memory` of both VirtualMachine instance show that the guest was assigned 512Mi memory. +The `.status.memory` of both VirtualMachine instances shows that the guest was assigned 512Mi memory. ```yaml apiVersion: kubevirt.io/v1 diff --git a/content/en/docs/instance-types-and-preferences/create-instancetype.md b/content/en/docs/instance-types-and-preferences/create-instancetype.md index df30e53..7d9d95f 100644 --- a/content/en/docs/instance-types-and-preferences/create-instancetype.md +++ b/content/en/docs/instance-types-and-preferences/create-instancetype.md @@ -1,30 +1,32 @@ --- -title: "Create an Instancetype" +title: "Create an instance type" weight: 33 labfoldernumber: "03" description: > - Create your own Instance type and Preference + Create your own instance type and preference --- -In this section we will create and use our own instance type. +In this section, we will create and use our own instance type. -## {{% task %}} Create your own Instancetype +## {{% task %}} Create your own instance type -In the previous section we have seen that the Cirros preference requests 256Mi of memory. However, the smallest Instancetype -available requested 512Mi of memory. Let's create our own Instancetype and assign it to our VirtualMachines. +In the previous section we have seen that the Cirros preference requests 256Mi of memory. However, the smallest instance type +available requests 512Mi of memory. In order to adapt to this, let's create our own instance type and assign it to our VirtualMachines. Create a file `vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml` under `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}` and start with the -definition of the `o1.nano` instancetype. +definition of the `o1.nano` instance type. -Define the Instancetype: +Define the instance type: * Request 256Mi of memory * Reduce the overcommit percentage from 50% to 25% -* Name the resource `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico`. +* Name the resource `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico` {{% details title="Task Hint" %}} -Your Instancetype should look like this (labels and annotations are optional): + +Your instance type should look like this (labels and annotations are optional): + ```yaml apiVersion: instancetype.kubevirt.io/v1beta1 kind: VirtualMachineInstancetype @@ -54,6 +56,7 @@ spec: {{% /details %}} Create your resource with: + ```bash kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml --namespace=$USER ``` @@ -65,19 +68,22 @@ kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %} ``` -## {{% task %}} Create your own Instancetype with virtctl +## {{% task %}} Create your own instance type with virtctl + +The `virtctl` tool is also capable of creating instance types. You can define and create a similar instance type `u1.pico` with: -The `virtctl` tool is also capable of creating Instancetypes. You can define and create a similar Instancetype `u1.pico` with: ```bash virtctl create instancetype --namespaced --cpu 1 --memory 256Mi --name {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico --namespace=$USER | kubectl create --namespace=$USER -f - ``` -Show the created Instancetype with +Show the created instance type with: + ```bash kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico -o yaml --namespace=$USER ``` The output will be similar to this one: + ```yaml apiVersion: instancetype.kubevirt.io/v1beta1 kind: VirtualMachineInstancetype diff --git a/content/en/docs/instance-types-and-preferences/reassign-instancetype.md b/content/en/docs/instance-types-and-preferences/reassign-instancetype.md index 19d135d..9b9eb73 100644 --- a/content/en/docs/instance-types-and-preferences/reassign-instancetype.md +++ b/content/en/docs/instance-types-and-preferences/reassign-instancetype.md @@ -1,26 +1,28 @@ --- -title: "Re-assign an Instancetype" +title: "Re-assign an instance type" weight: 34 labfoldernumber: "03" description: > - Re-assign an Instance type of your VM + Re-assign an instance type to your VM --- -In this section we will change the instancetype of our running VMs to our newly created instance type. +In this section we will change the instance type of our running VMs to our newly created instance type. -## Changing an Instancetype +## Changing an instance type -Whenever a VM referencing an instancetype or preference is created, the definition at time of creation is stored in a `ControllerRevision`. This revision is then referenced in a new field `.spec.instancetype.revisionName` in our VM manifest. +Whenever a VM referencing an instance type or preference is created, the definition at time of creation is stored in a `ControllerRevision`. This revision is then referenced in a new field `.spec.instancetype.revisionName` in our VM manifest. -This field ensures that our VirtualMachine knows the original specification even when the type or preference would be changed. This ensures that there are no accidental changes of the VM resources or preferences. +This field ensures that our VirtualMachine knows the original specification even when the type or preference would change. This ensures that there are no accidental changes to the VM resources or preferences. + +Use the following command to display the VM resource. You will find the reference to the revision under `spec.instancetype.revisionName`: -Use the following command to display the vm resource, you will find the reference to the revision under `spec.instancetype.revisionName`: ```bash kubectl get vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml --namespace=$USER ``` Example of a VM with a `revisionName`: + ```yaml [...] spec: @@ -31,7 +33,8 @@ spec: [...] ``` -Use the following command to list all available `controllerrevision`: +Use the following command to list all available `controllerrevision` resources: + ```bash kubectl get controllerrevision --namespace=$USER ``` @@ -43,13 +46,13 @@ NAME [...] ``` -If we want to explicitly change the Instancetype or preference we have to remove the `revisionName` attribute completely otherwise it will reject the change. +If we want to explicitly change the instance type or preference, we have to remove the `revisionName` attribute completely, otherwise it will reject the change with the following message: ```bash The request is invalid: spec.instancetype.revisionName: the Matcher Name has been updated without updating the RevisionName ``` -If we want to change the Instancetype in the resource and reapply the changes using `kubectl apply -f` we need to set the RevisionName to `null` +If we want to change the instance type in the resource and reapply the changes using `kubectl apply -f` we need to set the `revisionName` set to `null`: ```yaml [...] @@ -62,27 +65,29 @@ spec: ``` When editing the resource directly, we can simply remove the `revisionName`: + ```bash kubectl edit vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER ``` -Or alternatively, patch the resource directly with: +Or alternatively, patch the resource using: + ```bash kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"","name":"","revisionName":null}}}' --namespace=$USER ``` -## {{% task %}} Adapt your VMs to use the new instancetype +## {{% task %}} Adapt your VMs to use the new instance type -Change the InstanceTypes of the two VMs from the current VirtualMachineClusterInstancetype (`u1.nano`) to the InstanceType (`{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico` and `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico`) +Change the instance types of the two VMs from the current VirtualMachineClusterInstancetype (`u1.nano`) to instance type (`{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico` and `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico`) * `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros` * `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros` -Use one of the mentioned methods above, to change the resource. +Use one of the mentioned methods above to change the resource. {{% alert title="Note" color="info" %}} -Since so far we were referencing a `VirtualMachineClusterPreference` also change the kind to `VirtualMachineInstancetype` for our new InstanceTypes. +Since so far we were referencing a `VirtualMachineClusterPreference`, also change the kind to `VirtualMachineInstancetype` for our new instance types. And don't forget to remove the referenced `revisionName`. {{% /alert %}} @@ -98,6 +103,7 @@ spec: ``` For `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros` it will be: + ```yaml spec: instancetype: @@ -107,26 +113,31 @@ spec: {{% /details %}} -Make sure you restart both VMs to reflect the change of their instancetype: +Make sure you restart both VMs to reflect the changes to their instance type: + ```bash virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER ``` Verify whether the two VMIs are running again properly: + ```bash kubectl get vmi --namespace=$USER ``` Describe both VirtualMachine instances and observe the effect: + ```bash kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml --namespace=$USER ``` + ```bash kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml --namespace=$USER ``` The `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros` instance: + ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance @@ -143,6 +154,7 @@ spec: ``` `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros` instance: + ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance @@ -163,7 +175,8 @@ spec: {{% alert title="Cleanup resources" color="warning" %}} {{% param "end-of-lab-text" %}} -Stop your running VM with +Stop your running VM with: + ```bash virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER diff --git a/content/en/docs/instance-types-and-preferences/types-introduction.md b/content/en/docs/instance-types-and-preferences/types-introduction.md index e2f1a2f..79bb8cc 100644 --- a/content/en/docs/instance-types-and-preferences/types-introduction.md +++ b/content/en/docs/instance-types-and-preferences/types-introduction.md @@ -3,52 +3,51 @@ title: "Introduction" weight: 31 labfoldernumber: "03" description: > - Create your own Instancetype + Create your own instance type --- -Even if KubeVirt provides advanced options and a lot of configuration options for different VMs we usually have a common -set of VM specifications which we will use for most of our VMs. Therefore, it may make sense of defining such -specifications as Instancetypes and / or Preferences. +Even if KubeVirt provides advanced options and a lot of configuration options for different VMs, we usually have a common +set of VM specifications which we will use for most of our VMs. Therefore, it may make sense to define such +specifications as instance types and / or preferences. -To achieve this, KubeVirt provides multiple Custom Resource -Definitions like `VirtualMachineInstancetype`, `VirtualMachineClusterInstancetype` or `VirtualMachinePreference`. +To achieve this, KubeVirt provides multiple CustomResourceDefinitions like `VirtualMachineInstancetype`, `VirtualMachineClusterInstancetype` or `VirtualMachinePreference`. ## VM VirtualMachineInstancetype -For an Instancetype we have the option of using the cluster wide `VirtualMachineClusterInstancetype` or the namespaced +For an instance type we have the option of using the cluster-wide `VirtualMachineClusterInstancetype` or the namespaced `VirtualMachineInstancetype`. -With Instancetypes we can define the following resource related characteristics: +With instance types we can define the following resource-related characteristics: * **CPU** - Required number of vCPUs presented to the guest * **Memory** - Required amount of memory presented to the guest * **GPUs** - Optional list of vGPUs to passthrough -* **HostDevices** - Optional list of HostDevices to passthrough +* **HostDevices** - Optional list of HostDevices to pass through * **IOThreadsPolicy** - Optional IOThreadsPolicy to be used * **LaunchSecurity** - Optional LaunchSecurity to be used {{% alert title="Important" color="warning" %}} -Any provided Instancetype characteristic can not be overridden from within the VirtualMachine. Be aware that `CPU` and -`Memory` both are required for an Instancetype. Therefore, any different request of `CPU` or `Memory` on a VirtualMachine -will conflict and the request will be rejected. +Any provided instance type characteristic can not be overridden from within the VirtualMachine. Be aware that `CPU` and +`Memory` both are required for an instance type. Therefore, any different request of `CPU` or `Memory` on a VirtualMachine +resource will conflict and the request will be rejected. {{% /alert %}} -## VM Preference +## VM preference -KubeVirt also provides a CRD `VirtualMachineClusterPreference` for cluster wide preferences as well as a namespaced +KubeVirt also provides a CRD `VirtualMachineClusterPreference` for cluster-wide preferences as well as a namespaced version `VirtualMachinePreference`. A preference specification encapsulates every value of the remaining attributes of a VirtualMachine. {{% alert title="Note" color="info" %}} -Not like the characteristics from an Instancetype the preferences only defined the preferred values. They can be overridden +Unlike the characteristics from an instance type, the preferences only define the preferred values. They can be overridden in the VirtualMachine specification. The specification from the VirtualMachine has priority. {{% /alert %}} -## Using Instancetype or Preference in a virtual machine +## Using instance type or preference in a virtual machine -A sample virtual machine referencing an Instancetype and Preference can look like this: +A sample virtual machine referencing an instance type and preference looks like this: ```yaml apiVersion: kubevirt.io/v1