KubeVirt User Guide
  • KubeVirt User-Guide
  • docs
    • virtual_machines
      • NetworkPolicy
      • VirtualMachineInstanceReplicaSet
      • Dedicated CPU resources
      • Liveness and Readiness Probes
      • Istio service mesh
      • Run Strategies
      • Templates
      • Windows virtio drivers
      • Accessing Virtual Machines
      • Guest Operating System Information
      • Presets
      • Virtual hardware
      • Interfaces and Networks
      • Virtual Machines Instances
      • NUMA
      • Host Devices Assignment
      • Guest Agent information
      • Service objects
      • Lifecycle
      • DNS records
      • Disks and Volumes
      • Booting From External Source
      • Startup Scripts
    • operations
      • Node maintenance
      • virtctl Client Tool
      • Customize KubeVirt Components
      • Updating and deletion
      • Activating feature gates
      • Snapshot Restore API
      • Node assignment
      • Component monitoring
      • node_overcommit
      • Annotations and labels
      • Unresponsive nodes
      • API Validation
      • live_migration
      • Authorization
      • Hugepages support
      • Containerized Data Importer
      • Installation
      • Basic use
      • Hotplug Volumes
    • Latest release notes
    • Welcome
    • appendix
      • Contributing
    • Web Console
    • Architecture
  • Contributing guidelines
Powered by GitBook
On this page
  • Use cases
  • Workflow
  1. docs
  2. virtual_machines

Booting From External Source

PreviousDisks and VolumesNextStartup Scripts

Last updated 3 years ago

When installing a new guest virtual machine OS, it is often useful to boot directly from a kernel and initrd stored in the host physical machine OS, allowing command line arguments to be passed directly to the installer.

Booting from an external source is supported in Kubevirt starting from . This enables the capability to define a Virtual Machine that will use a custom kernel / initrd binary, with possible custom arguments, during its boot process.

The binaries are provided though a container image. The container is pulled from the container registry and resides on the local node hosting the VMs.

Use cases

Some use cases for this may be:

  • For a kernel developer it may be very convenient to launch VMs that are defined to boot from the latest kernel binary

    that is often being changed.

  • Initrd can be set with files that need to reside on-memory during all the VM's life-cycle.

Workflow

Defining an external boot source can be done in the following way:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ext-kernel-boot-vm
spec:
  runStrategy: Manual
  template:
    spec:
      domain:
        devices: {}
        firmware:
          kernelBoot:
            container:
              image: vmi_ext_boot/kernel_initrd_binaries_container:latest
              initrdPath: /boot/initramfs-virt
              kernelPath: /boot/vmlinuz-virt
              imagePullPolicy: Always
              imagePullSecret: IfNotPresent
            kernelArgs: console=ttyS0
        resources:
          requests:
            memory: 1Gi

Notes:

  • initrdPath and kernelPath define the path for the binaries inside the container.

  • Kernel and Initrd binaries must be owned by qemu user & group.

    • To change ownership: chown qemu:qemu <binary> when <binary> is the binary file.

  • kernelArgs can be provided even if a kernel binary is not provided (i.e. kernelPath not defined). These arguments will be passed to the default kernel the VM boots from.

  • imagePullSecret and imagePullPolicy are optional

  • if imagePullPolicy is Always and the container image is updated then the VM will be booted into the new kernel when VM restarts

version v0.42.0-rc.0