Initial Commit

vm/host/owuivm-maint@.service

@@ -0,0 +1,159 @@
+# =====================================================================
+# Maintenance mode: the operator unfreezing a base image to change it.
+#
+# THIS IS WHY THE AGENT CAN NEVER UNFREEZE ANYTHING
+#
+# The sandbox runs as owuivm. Base images are mode 0444 owned by
+# owuivmadm, in a directory owuivm does not own and is not in the group
+# of. So the uid that runs every session physically cannot clear a write
+# bit, and there is no verb in vmd that asks anyone else to.
+#
+# This unit is the only path that can, and it runs as owuivmadm. Starting
+# it is gated by polkit (50-owuivm.rules) on an ACTIVE LOCAL SESSION of
+# the operator - not on group membership, which a background process
+# could inherit. An agent asking for an unfreeze produces a sentence in a
+# report; a person at the machine is what produces a writable disk.
+#
+# FREEZING IS A chmod, WHICH MEANS IT IS VISIBLE
+#
+# `ls -l` says whether an image is frozen. This unit does not change it
+# in either direction: starting a machine and unfreezing its disk are
+# separate decisions, made by separate buttons, because the most useful
+# thing the operator can do is boot the image exactly as the agent will
+# get it - which must not be able to change it.
+#
+# A frozen disk therefore boots a throwaway overlay and ExecStopPost
+# throws it away; an unfrozen one boots itself and keeps what happens.
+# An image left unfrozen is caught where it matters rather than here:
+# vmd refuses to open a session on a writable base.
+# =====================================================================
+[Unit]
+Description=owuitools VM maintenance (%i base image)
+After=owuivm-nft-guard.service
+Requires=owuivm-nft-guard.service
+# Refuses to run while a session is live: one VM at a time, and two
+# processes with the same disk open is how a qcow2 gets corrupted.
+Conflicts=owuivm.service
+# Deliberately NO ConditionPathExists on the disk: starting this unit
+# with no image is how one gets installed. ExecStartPre creates a blank
+# disk and points the machine at the installation media.
+ConditionPathExists=/dev/kvm
+
+[Service]
+Type=simple
+User=owuivmadm
+Group=owuivmadm
+SupplementaryGroups=kvm
+# 0007 so the console socket qemu creates is group-writable, and the
+# directory's setgid bit makes that group the OPERATOR's - the person who has
+# to be able to connect to it.
+UMask=0007
+
+Environment=OWUIVM_MODE=maint
+Environment=OWUIVM_SESSION=00000000000000000000000000000000
+Environment=OWUIVM_MEM_MB=8192
+Environment=OWUIVM_CPUS=8
+Environment=OWUIVM_DISK=/var/lib/owuivm/base/%i.qcow2
+Environment=OWUIVM_VARS=/run/owuivm/00000000000000000000000000000000/OVMF_VARS.fd
+
+ExecStartPre=/usr/local/libexec/owuivm-maint-prepare %i open
+ExecStart=/usr/local/libexec/owuivm-launch
+# The power button first, then the tidying. Without this, stopping the
+# unit yanked power on the disk the operator was editing.
+ExecStop=/usr/local/libexec/owuivm-powerdown ${OWUIVM_SESSION}
+ExecStopPost=/usr/local/libexec/owuivm-maint-prepare %i close
+
+# The maintenance VM gets exactly the sandbox's network policy. It is the
+# operator driving it rather than an agent, but it is the same disk that
+# every session will later run from: if something is installed here that
+# only works because this VM could reach the LAN, that breaks later, in a
+# session, where it is much harder to see.
+IPAddressDeny=127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 100.64.0.0/10 192.0.0.0/24 224.0.0.0/4 240.0.0.0/4
+RestrictAddressFamilies=AF_UNIX AF_INET
+# No exception needed: the console is a unix socket, so this unit opens
+# no listening TCP port at all - the same as a session.
+SocketBindDeny=any
+
+DevicePolicy=closed
+DeviceAllow=/dev/kvm rw
+NoNewPrivileges=yes
+# THE SANDBOX GETS ITS OWN RESOLVER, AND THIS IS NOT COSMETIC.
+#
+# SLIRP hands every guest 10.0.2.3 as its nameserver over DHCP. That is a
+# forwarder inside the qemu process, and it relays to whatever the HOST's
+# /etc/resolv.conf says - here 127.0.0.53, systemd-resolved, which
+# forwards to the LAN's own DNS and knows every internal name in the
+# house. This unit denies 127.0.0.0/8, correctly, so that relay is dead.
+#
+# The result is a guest with working TCP to the internet and no name
+# resolution whatsoever, which presents as "no internet" and sends
+# whoever is looking at it to entirely the wrong place. It did exactly
+# that to a hand-installed image.
+#
+# Bind-mounting a resolv.conf of our own fixes it for every guest without
+# the guest being configured at all, and without the host's resolver ever
+# becoming reachable from the sandbox.
+BindReadOnlyPaths=/etc/owuivm/resolv.conf:/etc/resolv.conf
+
+ProtectSystem=strict
+ProtectHome=yes
+PrivateTmp=yes
+# The overlay dataset holds the throwaway disk of a frozen boot. It is the same
+# dataset a session's overlay lives on, and its 40 GB quota is what
+# stops a guest that writes forever from filling the root filesystem.
+ReadWritePaths=/run/owuivm /run/owuivm-maint /var/lib/owuivm/base @POOL_ROOT@/vmrun
+ProtectKernelTunables=yes
+ProtectKernelLogs=yes
+ProtectControlGroups=yes
+RestrictNamespaces=yes
+RestrictRealtime=yes
+LockPersonality=yes
+SystemCallArchitectures=native
+SystemCallFilter=@system-service
+# NOT optional, and its absence is not a smaller version of having it.
+# Without this, a filtered syscall raises SIGSYS and kills the process;
+# with it, the call returns EPERM and the caller decides what to do.
+# qemu calls seccomp(2) at startup to probe for its own sandbox - which
+# @system-service does not permit - so a maintenance boot died instantly
+# with status=31/SYS until this line was added, while a session boot,
+# which has always had it, simply got EPERM and carried on.
+SystemCallErrorNumber=EPERM
+
+# MEASURED: 10G made the machine crawl, and it was not obvious why.
+#
+# The guest's RAM is a memfd with share=on (virtiofs requires it), so the
+# kernel accounts all 8 GiB of it as *shmem* in this cgroup - and with no
+# swap on this host, shmem cannot be reclaimed at all. That left about
+# 1.5 GiB for every page of ISO and disk I/O the VM does, so the cgroup
+# hit its hard limit 6,782 times in one boot (memory.events max), evicting
+# and re-reading the same installer media over and over.
+#
+# The first fix was to raise this to 14G so the page cache had room.
+# That worked - reclaim went to zero - and it was the wrong fix: it gave
+# one VM twelve gigabytes of a 58 GB host that is also running Ollama,
+# and the host started running short instead. Raising a limit to make
+# room for something that should not have been in there.
+#
+# The right fix is one line in owuivm-launch: cache=none on every drive,
+# so this VM's I/O never enters the page cache at all. What is left in
+# the cgroup is the guest's RAM and qemu itself, which is what this limit
+# was always meant to bound. 11G is 8 GiB of guest, about 1 GiB of qemu,
+# and slack.
+MemoryMax=@VM_MEMORY_MAX@
+# 800%, NOT 700%, AND THE DIFFERENCE IS NOT THEORETICAL.
+#
+# The machine has 8 vCPUs, so 800% is exactly what it can consume and
+# 700% means one of its eight can never run. Measured during a Windows
+# install: qemu sat at 697% of the 700% ceiling, with 1,792 throttle
+# events and 103 seconds of CPU actually withheld - while the operator
+# watched a progress bar and wondered whether nested virtualisation was
+# to blame. It was not; it was this line.
+#
+# The session unit keeps 700% on purpose: it runs while the main model
+# may be answering someone, and it is pinned to eight threads that
+# Ollama can also use. A maintenance boot is one person doing one thing,
+# and it should have the whole machine it was given.
+CPUQuota=@MAINT_CPU_QUOTA@
+TasksMax=512
+TimeoutStopSec=120
+KillMode=mixed