From 7104984ac7c6852f37b65a3e0f19e94c0d6fc6c9 Mon Sep 17 00:00:00 2001 From: "Michael N. Lipp" Date: Fri, 7 Mar 2025 13:26:31 +0100 Subject: [PATCH] Consistent spelling for QEMU. --- webpages/controller.md | 4 ++-- webpages/index.md | 14 +++++++------- webpages/runner.md | 8 ++++---- webpages/upgrading.md | 2 +- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/webpages/controller.md b/webpages/controller.md index e20263f..c91e2d4 100644 --- a/webpages/controller.md +++ b/webpages/controller.md @@ -209,7 +209,7 @@ data: If such a secret for the VM is found, the VM is configured to use the display password specified. The display password in the secret can be updated while the VM runs[^delay]. Activating/deactivating -the display password while a VM runs is not supported by Qemu and +the display password while a VM runs is not supported by QEMU and therefore requires stopping the VM, adding/removing the secret and restarting the VM. @@ -220,7 +220,7 @@ restarting the VM. The secret's `data` can have an additional property `data.password-expiry` which specifies a (base64 encoded) expiry date for the password. Supported -values are those defined by qemu (`+n` seconds from now, `n` Unix +values are those defined by QEMU (`+n` seconds from now, `n` Unix timestamp, `never` and `now`). Unless `spec.vm.display.spice.generateSecret` is set to `false` in the VM diff --git a/webpages/index.md b/webpages/index.md index 9ad3aba..2f1afaf 100644 --- a/webpages/index.md +++ b/webpages/index.md @@ -12,10 +12,10 @@ layout: vm-operator ![Overview picture](index-pic.svg) This project provides an easy to use and flexible solution -for running Qemu/KVM based VMs in Kubernetes pods. +for running QEMU/KVM based VMs in Kubernetes pods. -The image used for the VM pods combines Qemu and a control program -for starting and managing the Qemu process. This application is called +The image used for the VM pods combines QEMU and a control program +for starting and managing the QEMU process. This application is called "[the runner](runner.html)". While you can deploy a runner manually (or with the help of some @@ -30,7 +30,7 @@ page and proceed to "[the manager](manager.html)". The project was triggered by a remark in the discussion about RedHat [dropping SPICE support](https://bugzilla.redhat.com/show_bug.cgi?id=2030592) -from the RHEL packages. Which means that you have to run Qemu in a +from the RHEL packages. Which means that you have to run QEMU in a container on RHEL and derivatives if you want to continue using Spice. So KubeVirt comes to mind. But [one comment](https://bugzilla.redhat.com/show_bug.cgi?id=2030592#c4) @@ -38,10 +38,10 @@ mentioned that the [KubeVirt](https://kubevirt.io/) project isn't interested in supporting SPICE either. Time to have a look at alternatives. Libvirt has become a common -tool to configure and run Qemu. But some of its functionality, notably +tool to configure and run QEMU. But some of its functionality, notably the management of storage for the VMs and networking is already provided by Kubernetes. Therefore this project takes a fresh approach of -running Qemu in a pod using a simple, lightweight manager called "runner". +running QEMU in a pod using a simple, lightweight manager called "runner". Providing resources to the VM is left to Kubernetes mechanisms as much as possible. @@ -50,7 +50,7 @@ much as possible. VMs are not the typical workload managed by Kubernetes. You can neither have replicas nor can the containers simply be restarted without a major impact on the "application". So there are many features for managing -pods that we cannot make use of. Qemu in its container can only be +pods that we cannot make use of. QEMU in its container can only be deployed as a pod or using a stateful set with replica 1, which is rather close to simply deploying the pod (you get the restart and some PVC management "for free"). diff --git a/webpages/runner.md b/webpages/runner.md index a877b57..e677a7a 100644 --- a/webpages/runner.md +++ b/webpages/runner.md @@ -9,19 +9,19 @@ layout: vm-operator # The Runner -For most use cases, Qemu needs to be started and controlled by another -program that manages the Qemu process. This program is called the +For most use cases, QEMU needs to be started and controlled by another +program that manages the QEMU process. This program is called the runner in this context. The most prominent reason for this second program is that it allows -a VM to be shutdown cleanly in response to a TERM signal. Qemu handles +a VM to be shutdown cleanly in response to a TERM signal. QEMU handles the TERM signal by flushing all buffers and stopping, leaving the disks in a [crash consistent state](https://gitlab.com/qemu-project/qemu/-/issues/148). For a graceful shutdown, a parent process must handle the TERM signal, send the `system_powerdown` command to the qemu process and wait for its completion. Another reason for having the runner is that another process needs to be started -before qemu if the VM is supposed to include a TPM (software TPM). +before QEMU if the VM is supposed to include a TPM (software TPM). Finally, we want some kind of higher level interface for applying runtime changes to the VM such as changing the CD or configuring the number of diff --git a/webpages/upgrading.md b/webpages/upgrading.md index 12ff096..a590bcc 100644 --- a/webpages/upgrading.md +++ b/webpages/upgrading.md @@ -29,7 +29,7 @@ layout: vm-operator but should be updated. * The standard [template](./runner.html#stand-alone-configuration) used - to generate the QEMU command has been updated. Unless you have enabled + to generate the qemu command has been updated. Unless you have enabled automatic updates of the template in the VM definition, you have to update the template manually. If you're using your own template, you have to add a virtual serial port (see the git history of the standard