lab 4 draft

content/en/docs/02/21_create-vm.md

@@ -21,6 +21,10 @@ metadata:
 spec:
   running: false
   template:
+    metadata:
+      labels:
+        kubevirt.io/size: small
+        kubevirt.io/domain: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm
     spec:
       domain:
         devices: {}
@@ -96,6 +100,10 @@ metadata:
 spec:
   running: false
   template:
+    metadata:
+      labels:
+        kubevirt.io/size: small
+        kubevirt.io/domain: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm
     spec:
       domain:
         devices:

content/en/docs/02/22_lifecycle.md

@@ -37,7 +37,7 @@ Since you created the VirtualMachine in the previous section you may verify the
 kubectl get virtualmachine
 ```
 
-The output should be as follows:
+You should see your virtual machines listed as following:
 
 ```shell
 NAME            AGE   STATUS    READY

content/en/docs/02/24_ssh.md

@@ -0,0 +1,128 @@
+---
+title: "2.4 Exposing VM Ports"
+weight: 240
+labfoldernumber: "02"
+sectionnumber: 2.4
+description: >
+  Accessing ports of the running VirtualMachine
+---
+
+In the previous section we accessed our VM console using the `virtctl` tool. In this section we will expose the SSH port
+of our VM and access it directly. 
+
+{{% alert title="Note" color="info" %}}
+This can be done for any port you want to use. For example if your virtual machine provides a webserver you can expose
+the webserver port. 
+{{% /alert %}}
+
+## Checking available Services
+
+As you see with the following command creating the VM does not create any kubernetes service for it.
+```shell
+kubectl get service
+```
+
+In your namespace you should only see the service of your webshell:
+```shell
+NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
+$USER-webshell   ClusterIP   10.43.248.212   <none>        3000/TCP   1d
+```
+
+## Exposing port 22(ssh) on the kubernetes pod network
+To access the SSH port from the kubernetes default pod network we have to create a simple service.
+For this we use a Service of type `ClusterIP`.
+
+The needed configuration for the kubernetes `Service` looks like this. Create a file `svc_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.yaml` and use the following yaml configuration.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh
+spec:
+  ports:
+  - port: 22
+    protocol: TCP
+    targetPort: 22
+  selector:
+    kubevirt.io/domain: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm
+    kubevirt.io/size: small
+  type: ClusterIP
+```
+
+Apply the service with:
+```shell
+kubectl apply -f `svc_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.yaml`
+```
+
+You may now log in from your webshell terminal to the ssh port of the virtual machine using the following command:
+```shell
+ssh cirros@{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh.$USER.svc.cluster.local
+```
+
+{{% alert title="Note" color="info" %}}
+Make sure you replace `$USER` in the command above with your namespace. It should be equivalent with your username.
+{{% /alert %}}
+
+{{% alert title="Note" color="info" %}}
+We could also use the `virtctl` command to create a service for us. The command for the service above would be:
+
+```shell
+virtctl expose vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --name={{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh --port=22
+```
+
+We will use this approach in the next section.
+{{% /alert %}}
+
+## Exposting SSH port for external use
+Our exposed Service with type `ClusterIP` is only reachable from within the kubernetes cluster. On our kubernetes
+cluster we can expose the port 22(ssh) as a `NodePort` service to access it from the outside of the cluster.
+
+This time we will use the `virtctl` command to expose the port as type `NodePort`. Us this command to create the Service:
+
+```shell
+virtctl expose vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm --name={{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh-np --port=22 --type=NodePort
+```
+
+If you check your services you should now see both services for your VM:
+```shell
+kubectl get service
+```
+
+Which should produce a similar output:
+```shell
+NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
+{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-firstvm-ssh   ClusterIP   10.43.89.29     <none>        22/TCP         17m
+{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-ssh-np        NodePort    10.43.223.242   <none>        22:32664/TCP   49s
+$USER-webshell      ClusterIP   10.43.248.212   <none>        3000/TCP       1d
+```
+
+With this, our service is reachable from every node on the indicated port. You may check the PORT(S) column for the
+assigned Port. In this example our assigned NodePort is `32664/TCP` which targets port 22 on our VM.
+
+To connect to the NodePort we actually need to know the IPs of our worker-nodes. You can directly get the IPs with:
+```shell
+kubectl get nodes --selector=node-role.kubernetes.io/master!=true -o jsonpath={.items[*].status.addresses[?\(@.type==\"ExternalIP\"\)].address}
+```
+
+Which will produce a similar output to this:
+```shell
+188.245.73.202 116.203.61.242 159.69.207.154
+```
+
+{{% alert title="Note" color="info" %}}
+You can also see the IPs of the nodes using:
+
+```shell
+kubectl get nodes -o wide
+```
+{{% /alert %}}
+
+Since the NodePort Service is accessible on any worker node you can simply pick one IP and issue the following command 
+from within your webshell (make sure you replace the IP and the assigned NodPort to match your details):
+```shell
+ssh [email protected] -p 32664
+```
+
+Using the NodePort is also possible from the outside. You should be able to use the same command from outside your
+webshell (for example from your Computer).

content/en/docs/02/24_vm-changes.md → content/en/docs/02/25_vm-changes.md

@@ -1,8 +1,8 @@
 ---
-title: "2.4 Changing files"
-weight: 240
+title: "2.5 Changing files"
+weight: 250
 labfoldernumber: "02"
-sectionnumber: 2.4
+sectionnumber: 2.5
 description: >
   Changing files in your running VM.
 ---

content/en/docs/02/_index.md

@@ -11,9 +11,11 @@ description: >
 ## Goals of this lab
 
 * Get familiar with the lab environment
-* Create our first VM using KubeVirt
-* Start and Stop a VM using virtctl or kubectl
+* Create your first VM using KubeVirt
+* Start and Stop a VM using `virtctl` or `kubectl`
 * Connect to the console of the VM
+* Expose and access ports of your VM
+* Making file changes to you VM and observe behaviour
 
 
 ## Folder structure

content/en/docs/04/41_types-introduction.md

@@ -0,0 +1,64 @@
+---
+title: "4.1 Introduction"
+weight: 410
+labfoldernumber: "04"
+sectionnumber: 4.1
+description: >
+  Introduction to virtual machine Instancetypes 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 of defining such
+specifications as Instancetypes and or Preferences. To achieve this, KubeVirt provides multiple Custom Resource
+Definitions like `VirtualMachineInstancetype`, `VirtualMachineClusterInstancetype` or `VirtualMachinePreference`. KubeVirt
+provides common defaults[^1] for Instancetypes and Preferences.
+
+## VM Instancetype
+For an Instancetype we have the option of using the cluster wide `VirtualMachineClusterInstancetype` or the namespaced
+`VirtualMachineInstancetype`.
+
+With Instancetypes 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
+* **IOThreadsPolicy** - Optional IOThreadsPolicy to be used
+* **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
+`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 %}}
+
+
+## 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.
+
+{{% alert title="Note" color="info" %}}
+Not like the characteristics from an Instancetype the preferences only defined 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
+
+A sample virtual machine referencing an Instancetype and Preference can look like this:
+
+```yaml
+apiVersion: kubevirt.io/v1
+kind: VirtualMachine
+metadata:
+  name: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-examplevm
+spec:
+  instancetype:
+    kind: VirtualMachineInstancetype
+    name: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-example-instancetype
+  preference:
+    kind: VirtualMachinePreference
+    name: {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-example-preference
+```
+
+[^1]: [Common Instancetypes](https://github.com/kubevirt/common-instancetypes)

content/en/docs/04/_index.md

@@ -5,3 +5,11 @@ labfoldernumber: "04"
 sectionnumber: 4
 ---
 
+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 be reused.
+
+## Lab Goals
+
+* Know the benefit of `VirtualMachineInstancetype` and `VirtualMachinePreference`
+* Define your own instance type and preference settings.
+* Use defined types and preferences for virtual machines.