Skip to content

Conversation

@mazunki
Copy link
Contributor

@mazunki mazunki commented Oct 17, 2025

This PR intends to take care of the permission issues regarding qemu-bridge-helper and ping.

For this, we add -helper= to the QEMU flags, which can be configured either through the vm.json, but more realistically through the fallback environment variable QEMU_BRIDGE_HELPER. If either of this is set, it'll tell qemu to use a specific bridge helper instead of the one it finds on PATH.

The second part of the puzzle is to find a bridge helper with capabilities set. While ${pkgs.qemu} offers a bridge-helper, there is no way the flake itself can override the system permissions on the flag. On NixOS, the /nix/store is mounted read-only, meaning that the user cannot override these capabilities even with sudo. What we can do, though, is install qemu-bridge-helper as a host package, and configure it to have the required permissions: this is exactly what nixos-module.nix does. Including this file from your system configuration.nix will install this for you, and even export the variable to your environment.

The last part of the puzzle, which this PR doesn't address at all, is to pass the environment variable we just set (/run/wrappers/bin/qemu-bridge-helper on NixOS, /usr/libexec/qemu-bridge-helper on Gentoo) to the test scripts. The easiest way to do this is to add --keep QEMU_BRIDGE_HELPER to nix-build or nix-shell --pure.

The downside to this approach is that patching QEMU's bridge helper will still require intervention, and there is a small concern of reproducibility by doing this (which was always the case due to the manual intervention, really). I suspect patching the bridge helper is not something which most people will do often.

By default, there is no change in behaviour at all.

Closes #43

@mazunki
Copy link
Contributor Author

mazunki commented Oct 17, 2025

All test are passing on both NixOS (which uses the module) and Gentoo (traditional configuration) for me. It's still required to call /nix/store/vbkqh5jrpmfb3d4h9b5y6sw5m433ld4j-create_bridge.sh after a reboot. The rest is automatic.

@mazunki mazunki force-pushed the feat-capabilities branch 3 times, most recently from ec06d0d to a429284 Compare October 18, 2025 00:47
@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

I have added a vmrunner-create-bridge binary available on PATH, which can automatically be updated through the system now. This way, we don't need to know the store hash of the derivation, and can potentially set up a script to launch it automatically.

In order to install it to the system, I have made a flake. This is mainly because of ./default.nix, which sets up the bridge shellscript, usually being located on a restricted path location (i.e. under /home). NixOS does not allow installing derivations from unsafe paths to the system by default.

While one could move the vmrunner repository to an unrestricted location or unlock this sandbox, this can be cumbersome. Flakes don't have this restriction because of how they handle inputs.

{
  description = "maz is a snowflake";
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";

    vmrunner.url = "github:includeos/vmrunner";
    vmrunner.inputs.nixpkgs.follows = "nixpkgs";
  };
  outputs = { self, nixpkgs, vmrunner, ... } @ inputs: let
    inherit (self) outputs;
  in {
    nixosConfigurations = {
      quack = nixpkgs.lib.nixosSystem {
        specialArgs = {inherit inputs outputs;};
        modules = [
            ./nixos/configuration.nix
            vmrunner.nixosModules.default
        ];
      };
    };
  };
}

If one needs to temporarily override vmrunner to apply their own patches but don't want to modify their config they can also do:

sudo nixos-rebuild switch --flake .#quack \
  --override-input vmrunner path:/home/maz/repos/includeos/vmrunner

@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

This PR is derived from #44. Without proper shebangs we can't run any of this.

@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

Again, IncludeOS tests are passing with these changes, but it's probably worth having someone else see how the automatic setup works for them. I am not really sure if there's a good way to write a repeatable test for this without a clean filesystem slate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Handle capabilities through a nix wrapper instead of requiring manual intervention

1 participant