From 1bb61b919ca73abad4def6752e8b56b88b020dd9 Mon Sep 17 00:00:00 2001 From: Thomas Philipona Date: Wed, 4 Sep 2024 18:47:34 +0200 Subject: [PATCH 1/2] Add Feedback Lab4 --- content/en/docs/04/41_types-introduction.md | 8 ++-- content/en/docs/04/42_common-instancetypes.md | 38 +++++++++---------- content/en/docs/04/43_create-instancetype.md | 16 ++++++-- .../en/docs/04/44_reassign-instancetype.md | 18 ++++----- content/en/docs/04/_index.md | 8 ++-- 5 files changed, 48 insertions(+), 40 deletions(-) diff --git a/content/en/docs/04/41_types-introduction.md b/content/en/docs/04/41_types-introduction.md index 64a496c..9934e8e 100644 --- a/content/en/docs/04/41_types-introduction.md +++ b/content/en/docs/04/41_types-introduction.md @@ -9,13 +9,13 @@ description: > 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. +specifications as Instancetypes and / or Preferences. To achieve this, KubeVirt provides multiple Custom Resource Definitions like `VirtualMachineInstancetype`, `VirtualMachineClusterInstancetype` or `VirtualMachinePreference`. -## VM Instancetype +## VM VirtualMachineInstancetype For an Instancetype we have the option of using the cluster wide `VirtualMachineClusterInstancetype` or the namespaced `VirtualMachineInstancetype`. @@ -30,7 +30,7 @@ With Instancetypes we can define the following resource related characteristics: * **LaunchSecurity** - Optional LaunchSecurity to be used {{% alert title="Important" color="warning" %}} -Any provided Instancetype characteristic cannot be overridden from within the VirtualMachine. Be aware that `CPU` and +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. {{% /alert %}} @@ -39,7 +39,7 @@ will conflict and the request will be rejected. ## VM Preference 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 attribues of a VirtualMachine. +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 diff --git a/content/en/docs/04/42_common-instancetypes.md b/content/en/docs/04/42_common-instancetypes.md index 181679f..99f48f9 100644 --- a/content/en/docs/04/42_common-instancetypes.md +++ b/content/en/docs/04/42_common-instancetypes.md @@ -4,20 +4,23 @@ weight: 420 labfoldernumber: "04" sectionnumber: 4.2 description: > - Discover and user Common Instancetypes and Preferences provided by KubeVirt. + Discover and use common Instancetypes 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 [Common Instancetypes and Preferences](https://github.com/kubevirt/common-instancetypes) provides a set of Instancetypes and Preferences. ## Deployment of Common Instancetypes 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 Instancetypes and Preferences are not available by default. They have to be deployed manually or using a feature gate of the KubeVirt operator. You can check the configuration on the KubeVirt CustomResource: ```shell -kubectl get kubevirt kubevirt -n kubevirt -o jsonpath={.spec.configuration.developerConfiguration.featureGates} +kubectl get kubevirt kubevirt --namespace=kubevirt -o jsonpath={.spec.configuration.developerConfiguration.featureGates} +``` +or +```shell +kubectl get kubevirt kubevirt --namespace=kubevirt -o yaml ``` The relevant section on the CustomResource is the following: @@ -34,16 +37,13 @@ spec: [...] ``` -With the feature gate enabled, the operator itself takes care of deploying the cluster wide common instance types and preferences. +With the feature gate enabled, the operator itself takes care of deploying the cluster wide common Instancetypes and Preferences. ### Manually deploy the Common Instancetypes and Preferences -If you want to deploy the instance types and preferences manually, simply apply them using the kustomize flag `-k`: - -```shell -kubectl apply -k https://github.com/kubevirt/common-instancetypes.git -``` +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/). ## List and inspect Instancetypes @@ -160,7 +160,7 @@ centos.7 10m You may see the details of a preference by describing the resource: ```shell -kubectl describe virtualmachineclusterpreference windows.10 +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: @@ -333,8 +333,8 @@ Deploy two VMs with different instance types: * 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` -{{% details title="Task Hint" %}} -`vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` specification: +{{% details title="Task Hint: Solution" %}} +`{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` specification: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine @@ -374,7 +374,7 @@ spec: userDataBase64: SGkuXG4= ``` -`vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` specification: +`{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` specification: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine @@ -416,8 +416,8 @@ spec: Apply and start both VMs with ```shell -kubectl apply -f vm_lab04-u1-cirros.yaml -kubectl apply -f vm_lab04-o1-cirros.yaml +kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_lab04-u1-cirros.yaml --namespace=$USER +kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_lab04-o1-cirros.yaml --namespace=$USER virtctl start lab04-u1-cirros virtctl start lab04-o1-cirros ``` @@ -445,8 +445,8 @@ and `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros {{% details title="Task Hint" %}} Describe both VirtualMachine instances using: ```shell -kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml -kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml +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 ``` The `lab04-u1-cirros` instance: diff --git a/content/en/docs/04/43_create-instancetype.md b/content/en/docs/04/43_create-instancetype.md index 91fbdc5..ed45668 100644 --- a/content/en/docs/04/43_create-instancetype.md +++ b/content/en/docs/04/43_create-instancetype.md @@ -15,7 +15,7 @@ In this section we will create and use our 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. -Create a file `vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml` and start with the +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. Define the Instancetype: @@ -56,20 +56,28 @@ spec: Create your resource with: ```shell -kubectl create -f vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml +kubectl create -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml --namespace=$USER ``` +And verify whether the creation was successful: + +```shell +kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico --namespace=$USER +``` + + + ## {{% task %}} Create your own Instancetype with virtctl The `virtctl` tool is also capable of creating Instancetypes. You can define and create a similar Instancetype `u1.pico` with: ```shell -virtctl create instancetype --namespaced --cpu 1 --memory 256Mi --name {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico | kubectl create -f - +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 ```shell -kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico -o yaml +kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico -o yaml --namespace=$USER ``` The output will be similar to this one: diff --git a/content/en/docs/04/44_reassign-instancetype.md b/content/en/docs/04/44_reassign-instancetype.md index 798c303..7482507 100644 --- a/content/en/docs/04/44_reassign-instancetype.md +++ b/content/en/docs/04/44_reassign-instancetype.md @@ -29,7 +29,7 @@ spec: Use the following command to list all available `controllerrevision`: ```shell -kubectl get controllerrevision +kubectl get controllerrevision --namespace=$USER ``` ``` @@ -43,12 +43,12 @@ If we want to explicitly change the Instancetype or preference we have to remove The easies way is to edit the resource directly is: ```shell -kubectl edit vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros +kubectl edit vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER ``` An alternative would be patching the resource directly with: ```shell -kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"","name":"","revisionName":null}}}' +kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"","name":"","revisionName":null}}}' --namespace=$USER ``` @@ -77,14 +77,14 @@ spec: Make sure you restart both VMs to reflect the change of their instancetype: ```shell -virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros +virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER +virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER ``` Describe both VirtualMachine instances and observe the effect: ```shell -kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml -kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml +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 ``` The `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros` instance: @@ -126,7 +126,7 @@ spec: Stop your running VM with ```shell -virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros +virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER +virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER ``` {{% /alert %}} diff --git a/content/en/docs/04/_index.md b/content/en/docs/04/_index.md index ac5634c..4467044 100644 --- a/content/en/docs/04/_index.md +++ b/content/en/docs/04/_index.md @@ -14,7 +14,7 @@ runtime characteristics like resources or performance settings which can then be ## Lab Goals * Know the benefit of `VirtualMachineInstancetype` and `VirtualMachinePreference` -* Examine Common Instance type and Preferences -* Deploy VMs with a common instancetype -* 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. From 18b300e64604514c68660ed3d60bb13383cafe3f Mon Sep 17 00:00:00 2001 From: Thomas Philipona Date: Wed, 4 Sep 2024 18:49:30 +0200 Subject: [PATCH 2/2] fix linter --- content/en/docs/04/43_create-instancetype.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/en/docs/04/43_create-instancetype.md b/content/en/docs/04/43_create-instancetype.md index ed45668..8c8685c 100644 --- a/content/en/docs/04/43_create-instancetype.md +++ b/content/en/docs/04/43_create-instancetype.md @@ -62,12 +62,10 @@ kubectl create -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" And verify whether the creation was successful: ```shell -kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico --namespace=$USER +kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico --namespace=$USER ``` - - ## {{% task %}} Create your own Instancetype with virtctl The `virtctl` tool is also capable of creating Instancetypes. You can define and create a similar Instancetype `u1.pico` with: