160 lines
7.5 KiB
Desktop File
160 lines
7.5 KiB
Desktop File
# =====================================================================
|
|
# 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
|