Booting a VM of an iSCSI LUN - inside a Kubernetes cluster
Create some entities in Kubernetes:
# Create the pod, services, persistent volumes, and claims
$ kubectl create -f iscsi-demo-target-tgtd.yaml
persistentvolumeclaim "disk-custom" created
persistentvolumeclaim "disk-alpine" created
persistentvolumeclaim "disk-cirros" created
persistentvolume "iscsi-disk-custom" created
persistentvolume "iscsi-disk-alpine" created
persistentvolume "iscsi-disk-cirros" created
service "iscsi-demo-target" created
pod "iscsi-demo-target-tgtd" created
Now use a pod to access the created target:
# Run a qemu instance to see if the target can be used
# Note: This is not testing the PV or PVC, just the service and target
# Use ctrl-a c quit to quit
$ kubectl run --rm -it qemu-test --image=kubevirt/libvirtd -- \
qemu-system-x86_64 \
-snapshot \
-drive file=iscsi://iscsi-demo-target/iqn.2017-01.io.kubevirt:sn.42/2 \
-nographic
And enjoy the boot:
ISOLINUX 6.04 6.04-pre1 Copyright (C) 1994-2015 H. Peter Anvin et al
boot:
OpenRC 0.21.7.818fc79999 is starting up Linux 4.4.45-0-virtgrsec (x86_64)
…
Welcome to Alpine Linux 3.5
Kernel 4.4.45-0-virtgrsec on an x86_64 (/dev/ttyS0)
localhost login:
Okay - It’s not all end-to-end yet - when looking at it from a KubeVirt perspective.
What you see is that a qemu instance is booting of an iSCSI target LUN, offered by an iSCSI portal running as an unprivileged pod on a Kubernetes cluster.
But that’s already nice, what was achieved so far:
- iSCSI target pod with demo content
- Service, volumes, claims to expose the content
qemu
can boot from the LUN- VM object can be created to boot of the LUN (if you specify the LUN)
The remaining gap (which is being worked on) is to allow specifying a claim in the VM object (instead of the LUN as we did it above). And then we can use KubeVirt to boot a VM of a disk image - probably.
::: {#footer} [ February 28th, 2017 10:38pm ]{#timestamp} [kubernetes]{.tag} [kubevirt]{.tag} [qemu]{.tag} [libvirtd]{.tag} [fedora]{.tag} [iscsi]{.tag} :::