Fix trailing space.

This commit is contained in:
Michael Lipp 2025-01-30 22:17:35 +01:00
parent 150b9f2908
commit ecd7ba7baf
10 changed files with 97 additions and 97 deletions

View file

@ -15,9 +15,9 @@ 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
While you can deploy a runner manually (or with the help of some
helm templates), the preferred way is to deploy "[the manager](manager.html)"
application which acts as a Kubernetes operator for runners
application which acts as a Kubernetes operator for runners
and thus the VMs.
If you just want to try out things, you can skip the remainder of this
@ -25,11 +25,11 @@ page and proceed to "[the manager](manager.html)".
## Motivation
The project was triggered by a remark in the discussion about RedHat
[dropping SPICE support](https://bugzilla.redhat.com/show_bug.cgi?id=2030592)
[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
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)
[one comment](https://bugzilla.redhat.com/show_bug.cgi?id=2030592#c4)
mentioned that the [KubeVirt](https://kubevirt.io/) project isn't
interested in supporting SPICE either.
@ -44,7 +44,7 @@ much as possible.
## VMs and Pods
VMs are not the typical workload managed by Kubernetes. You can neither
have replicas nor can the containers simply be restarted without a major
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
deployed as a pod or using a stateful set with replica 1, which is rather
@ -57,6 +57,6 @@ A second look, however, reveals that Kubernetes has more to offer.
* Its managing features *are* useful for running the component that
manages the pods with the VMs.
And if you use Kubernetes anyway, well then the VMs within Kubernetes
And if you use Kubernetes anyway, well then the VMs within Kubernetes
provide you with a unified view of all (or most of) your workloads,
which simplifies the maintenance of your platform.