Consistent spelling for QEMU.

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

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").

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

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