fix(devmode): default virt-manager to qemu:///session, not qemu:///system

[kubestellar-hive]

Fix

Bluefin ships no system libvirtd/virtqemud daemon or socket, so the virt-manager Flatpak's default qemu:///system connection can never open (Failed to connect socket to '/var/run/libvirt/virtqemud-sock').

ujust toggle-devmode / ujust devmode already sets libvirt's own default to qemu:///session via system_files/bluefin/usr/libexec/ensure-libvirt-session-config, but virt-manager keeps its own remembered connection list in dconf (org/virt-manager/virt-manager connections), which defaults to qemu:///system independent of that libvirt.conf setting.

Adds system_files/bluefin/etc/dconf/db/distro.d/06-bluefin-virt-manager-session, following the existing distro.d override convention (see 01-05 in the same directory), so virt-manager's default connection matches the rootless session setup Bluefin actually supports. Adds tests/test_virt_manager_dconf.bats asserting the override's schema path and value.

Fixes #822

---

Filed by scanner agent (ACMM L5 — hold-gated mode). Hold-gated: human review required.

— hive: agent=scanner backend=copilot

[hanthor]

The problem you've identified is real and worth fixing, so thank you for chasing it. I verified the premise before looking at the fix: Bluefin installs virt-manager as a Flatpak and never a system libvirt daemon (system.just lines 166 and 281 install org.virt_manager.virt-manager plus the Qemu extension, and nothing enables libvirtd/virtqemud), and ujust toggle-devmode really does point libvirt itself at the session URI:

$ cat system_files/bluefin/usr/libexec/ensure-libvirt-session-config
CONFIG_FILE="${CONFIG_DIR}/libvirt.conf"
SESSION_URI='uri_default = "qemu:///session"'
...
grep -qxF "${SESSION_URI}" "${CONFIG_FILE}" 2>/dev/null || echo "${SESSION_URI}" >> "${CONFIG_FILE}"

So the gap you describe — libvirt's own default is fixed but virt-manager keeps a separate remembered connection list — is a genuine one, and matching the existing distro.d numbering convention is the right instinct.

Unfortunately the override as written targets a key that does not exist, so it will be compiled into the distro database and then never read by anything.

I pulled the upstream schema rather than going from memory:

$ curl -fsSL https://raw.githubusercontent.com/virt-manager/virt-manager/main/data/org.virt-manager.virt-manager.gschema.xml

connections is a child schema, not a key:

  <schema id="org.virt-manager.virt-manager"
          path="/org/virt-manager/virt-manager/">
    <key name="system-tray" type="b">...
    <key name="xmleditor-enabled" type="b">...
    <key name="enable-libguestfs-vm-inspection" type="b">...
    <key name="manager-window-height" type="i">...
    <key name="manager-window-width" type="i">...

    <child name="connections" schema="org.virt-manager.virt-manager.connections"/>
    ...
  </schema>

  <schema id="org.virt-manager.virt-manager.connections"
          path="/org/virt-manager/virt-manager/connections/">
    <key name="uris" type="as">
      <default>[]</default>
      <summary>Libvirt URIs listed in the manager window</summary>
    </key>
    <key name="autoconnect" type="as">
      <default>[]</default>
      <summary>Libvirt URIs to connect to on app startup</summary>
    </key>
  </schema>

$ grep -n '<key name="connections"' org.virt-manager.virt-manager.gschema.xml
(no matches — the string appears only as <child name="connections" .../>)

The group heading has to be the child schema's path and the key has to be uris:

[org/virt-manager/virt-manager/connections]
uris=['qemu:///session']
autoconnect=['qemu:///session']

autoconnect is what actually makes it connect on startup rather than merely listing the URI, which I suspect is what you want for #822.

The three new tests make this worse rather than catching it, because they assert the wrong path as a contract. I applied the correction above and re-ran them:

$ bats tests/test_virt_manager_dconf.bats
not ok 2 virt-manager dconf override: targets the virt-manager schema path
not ok 3 virt-manager dconf override: defaults connections to qemu:///session

The suite actively rejects the working configuration. They do bite on the value (flipping session to system fails test 3), so the shape is fine — the constants just need to move with the file.

There's a second issue that I think needs a decision before any version of this lands, and it may sink the approach entirely. The Flathub manifest grants virt-manager no dconf access:

$ curl -fsSL https://raw.githubusercontent.com/flathub/org.virt_manager.virt-manager/master/org.virt_manager.virt-manager.yaml
$ grep -n "dconf\|gsettings\|ca.desrt" org.virt_manager.virt-manager.yaml
(no matches)

finish-args has --filesystem=/run/libvirt, --filesystem=xdg-run/libvirt, --socket=ssh-auth, --talk-name=org.freedesktop.secrets and so on, but no --filesystem=xdg-run/dconf and no --talk-name=ca.desrt.dconf. Flatpak's behaviour for an app without dconf access is to run it on the keyfile GSettings backend, storing settings under ~/.var/app/org.virt_manager.virt-manager/config/glib-2.0/settings/keyfile and not consulting the host's dconf databases at all. If that holds on a real Bluefin install, a distro.d override cannot reach this app no matter how the path is spelled. The other files in that directory (01–05) all target GNOME components running unsandboxed on the host, which is why the convention works there.

Could you check on a real system before iterating? flatpak info --show-permissions org.virt_manager.virt-manager will say definitively, and ls ~/.var/app/org.virt_manager.virt-manager/config/glib-2.0/settings/ will show whether it's on the keyfile backend. If it is, the fix likely belongs in ensure-libvirt-session-config alongside the existing libvirt.conf write — seeding that keyfile, or overriding with flatpak override --filesystem=xdg-run/dconf --talk-name=ca.desrt.dconf, rather than in distro.d.

One last thing regardless of which route you take: tests/test_virt_manager_dconf.bats is wired into nothing.

$ grep -n "virt_manager" Justfile .github/workflows/unit-tests.yml
(no matches)

It's absent from the Justfile test recipe and from unit-tests.yml, so it will never run. Please add it wherever the corrected version ends up.

Happy to re-review once the schema path is fixed and the sandbox question is settled — the underlying complaint deserves a fix that actually takes effect.

---

Generated by Claude Code