3.4. Re-assign an instance type

Re-assign an instance type to your VM

In this section we will change the instance type of our running VMs to our newly created instance type.

Changing an instance type

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 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:

kubectl get vm lab03-u1-cirros -o yaml --namespace lab-<username>

Example of a VM with a revisionName:

[...]
spec:
  instancetype:
    kind: VirtualMachineClusterInstancetype
    name: u1.nano
    revisionName: lab03-u1-cirros-u1.nano-v1beta1-e15b4047-3ff9-4308-9cd7-9f30b25336e0-1
[...]

Use the following command to list all available controllerrevision resources:

kubectl get controllerrevision --namespace lab-<username>

NAME                                                                                     CONTROLLER                                   REVISION   AGE
lab03-o1-cirros-cirros-v1beta1-fa1da1cd-7e10-4e89-a8ac-5bded8f7129e-1                    virtualmachine.kubevirt.io/lab03-o1-cirros   0          2h
lab03-u1-cirros-cirros-v1beta1-fa1da1cd-7e10-4e89-a8ac-5bded8f7129e-1                    virtualmachine.kubevirt.io/lab03-u1-cirros   0          2h
[...]

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:

The request is invalid: spec.instancetype.revisionName: the Matcher Name has been updated without updating the RevisionName

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:

[...]
spec:
  instancetype:
    kind: VirtualMachineClusterInstancetype
    name: u1.nano
    revisionName: null
[...]

When editing the resource directly, we can simply remove the revisionName:

kubectl edit vm lab03-u1-cirros --namespace lab-<username>

Or alternatively, patch the resource using:

kubectl patch vm lab03-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"<KIND>","name":"<NAME>","revisionName":null}}}' --namespace lab-<username>

Task 3.4.1: Adapt your VMs to use the new instance type

Change the instance types of the two VMs from the current VirtualMachineClusterInstancetype (u1.nano) to instance type (lab03-u1-pico and lab03-o1-pico)

  • lab03-u1-cirros
  • lab03-o1-cirros

Use one of the mentioned methods above to change the resource.

Task hint

The relevant section for the VM lab03-u1-cirros should look like this:

spec:
  instancetype:
    kind: VirtualMachineInstancetype
    name: lab03-u1-pico

For lab03-o1-cirros it will be:

spec:
  instancetype:
    kind: VirtualMachineInstancetype
    name: lab03-o1-pico

Make sure you restart both VMs to reflect the changes to their instance type:

virtctl restart lab03-u1-cirros --namespace lab-<username>
virtctl restart lab03-o1-cirros --namespace lab-<username>

Verify whether the two VMIs are running again properly:

kubectl get vmi --namespace lab-<username>

Describe both VirtualMachine instances and observe the effect:

kubectl get vmi lab03-u1-cirros -o yaml --namespace lab-<username>

kubectl get vmi lab03-o1-cirros -o yaml --namespace lab-<username>

The lab03-u1-cirros instance:

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: lab03-u1-cirros
spec:
  domain:
    resources:
      requests:
        memory: 256Mi
    memory:
      guest: 256Mi
[...]

lab03-o1-cirros instance:

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: lab03-o1-cirros
spec:
  domain:
    resources:
      requests:
        memory: 192Mi
    memory:
      guest: 256Mi
[...]

End of lab

Previous
Next