Skip to content

configuring-vm-render.md

Latest commit

 

History

History
94 lines (64 loc) · 3.59 KB

configuring-vm-render.md

File metadata and controls

94 lines (64 loc) · 3.59 KB
Raw

Configuring VM application rendering

The Flight Control worker converts VmApplication manifests into Quadlet units with vm-to-quadlet before devices receive the rendered application. You can configure the virt-launcher image and passt workarounds used during that conversion.

Defaults

Setting Default
launcherImage quay.io/kubevirt/virt-launcher:v1.8.4 (built into the worker; leave config unset or empty to use it)
passtWorkarounds true

passtWorkarounds enables startup patches for known networking issues in older virt-launcher passt builds (for example guest network instability and related passt failures). Keep this enabled unless your virt-launcher image already includes a fixed passt build.

Prerequisites

  • Flight Control deployed with the worker service (flightctl-worker)

Configuration reference

Parameter Type Description
worker.vmRender.launcherImage string Container image reference for the KubeVirt virt-launcher compute container. Leave empty to use the worker built-in default.
worker.vmRender.passtWorkarounds boolean When true, enable passt networking workarounds in generated Quadlet units.

Kubernetes (Helm)

Set the values under worker.vmRender. Leave launcherImage empty unless you need an override:

worker:
  vmRender:
    launcherImage: ""
    passtWorkarounds: true

Apply the chart upgrade, then restart the worker so it reloads configuration:

helm upgrade flightctl ./deploy/helm/flightctl -n <namespace> -f values.yaml
kubectl rollout restart deployment/flightctl-worker -n <namespace>

Podman Quadlet

Edit /etc/flightctl/service-config.yaml only when you need overrides. Omit launcherImage to keep the worker default:

worker:
  vmRender:
    passtWorkarounds: true

Restart the worker so the config template is re-rendered and the service reloads:

sudo systemctl restart flightctl-worker.service

Air-gapped environments

The default virt-launcher image is pulled by devices when they run VM applications. It is not part of the control-plane image set produced by flightctl-mirror-images.

In an air-gapped deployment:

  1. Mirror quay.io/kubevirt/virt-launcher:v1.8.4 (or your chosen virt-launcher image) to a registry that devices can reach.
  2. Set worker.vmRender.launcherImage to that mirrored reference so rendered Quadlet units pull from the mirror.
  3. Restart the worker, then re-render devices that already have VM applications so they pick up the new image reference.

Example (community / upstream registry):

INTERNAL=registry.example.com:5000
skopeo copy --all \
  docker://quay.io/kubevirt/virt-launcher:v1.8.4 \
  docker://${INTERNAL}/kubevirt/virt-launcher:v1.8.4
worker:
  vmRender:
    launcherImage: "registry.example.com:5000/kubevirt/virt-launcher:v1.8.4"
    passtWorkarounds: true

There is currently no separate Red Hat product virt-launcher image in the Flight Control packaging set. Use the upstream quay.io/kubevirt/virt-launcher reference, or another virt-launcher image you supply, and point launcherImage at the mirrored location.

After changing settings

Conversion results are cached by vm.yaml content and these render options. Changing launcherImage or passtWorkarounds affects newly rendered devices. Re-render existing devices (for example by updating the device or fleet) if they must pick up the new settings.

Related information