nixos/nixos-build-vms: use pkgs.qemu for virtualisation

[Ma27]

Motivation for this change

When I test a change e.g. in the module system manually, I usually use
nixos-build-vms(8) which also gives me a QEMU window where I can play
around in the freshly built VM.

It seems as this has changed recently when the default package for
non-interactive VM tests using the same framework was switched to
pkgs.qemu_test to reduce the closure size. While this is a reasonable
decision for our CI tests, I think that you really want a QEMU window of
the VM by default when using nixos-build-vms(8).

[1] bc2188b

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[andir]

Looks reasonable. Sorry for breaking your workflow :)

[rnhmjoj]

I'm not too familiar with this tool. Is nixos-build-vms purpose to build testing machines or any network of NixOS VMs (in production)? If it's the latter, then perhaps it shouldn't be using nixos/lib/testing-python.nix.

In any case, I think it would be better if testing-python.nix would take an interactive option, to make more obvious what's going on.

[Ma27]

It's intended to be a testing tool as it only starts a QEMU user session just like the NixOS testing framework.

In any case, I think it would be better if testing-python.nix would take an interactive option, to make more obvious what's going on.

Not sure if having another option doing (usually) the exact same thing is an actual benefit. Improving the option's description may be better.

[andir]

It's intended to be a testing tool as it only starts a QEMU user session just like the NixOS testing framework.

In any case, I think it would be better if testing-python.nix would take an interactive option, to make more obvious what's going on.

Not sure if having another option doing (usually) the exact same thing is an actual benefit. Improving the option's description may be better.

Actually, the change I did in #49403 adds the driverInteractive attribute that will use the full-blown QEMU for local test execution (including sdl, audio, gtk, …).

[rnhmjoj]

Ah, cool. So, shouldn't this be enough?

--- a/nixos/modules/installer/tools/nixos-build-vms/build-vms.nix
+++ b/nixos/modules/installer/tools/nixos-build-vms/build-vms.nix
@@ -15,4 +15,4 @@ with import ../../../../lib/testing-python.nix {
   pkgs = import ../../../../.. { inherit system config; };
 };
 
-(makeTest { inherit nodes; testScript = ""; }).driver
+(makeTest { inherit nodes; testScript = ""; }).driverInteractive

I'm not sure how I to test this...

[Ma27]

@rnhmjoj with a command like this:

$ cat foo.nix
{ vm = {}; }
$ nixos-build-vms -I nixpkgs=`pwd` foo.nix

@andir not sure if I'm missing something, but using driverInteractive doesn't open a QEMU window.

[andir]

@rnhmjoj with a command like this:

$ cat foo.nix
{ vm = {}; }
$ nixos-build-vms -I nixpkgs=`pwd` foo.nix

@andir not sure if I'm missing something, but using driverInteractive doesn't open a QEMU window.

Oh yeah I see the issue now. I somehow did expect that the driver script was the only place that required the variable qemu parameter. I'll have to pass it down the module system eval as well. I'll get to work on fixing that right away.

[Ma27]

@andir I can take care of it as well here :) Not sure if I can get to it tonight though.

[andir]

@andir I can take care of it as well here :) Not sure if I can get to it tonight though.

I think you'll need the change proposed in this PR anyway. The entire test runner script has to be a bit refactored. Currently we are specifying the qemu package on waaaaay too many places. I'd like the module system to be the only place where it is being defined and then we just stick with that.

[andir]

I think I've a workable solution: https://github.com/andir/nixpkgs/tree/nixos-build-vms-qemu

I didn't want to push it to this branch (just yet) as this change here can go in as is. I'd like to get some feedback on my additional proposed changes if things then work as expected with your use-case (and with -A driverInteractive)

[Ma27]

@andir fair enough. Does that mean I should merge the PR for now? You can revert the change and switch to driverInteractive as soon as your refactoring is completed, right?

[andir]

Yes, just merge this. This is good from my point of view.

[Ma27]

Done. Thanks a lot for your review and your work on this! :)