pyrox.dev
1# Running Tests interactively {#sec-running-nixos-tests-interactively}
2
3The test itself can be run interactively. This is particularly useful
4when developing or debugging a test:
5
6```ShellSession
7$ nix-build . -A nixosTests.login.driverInteractive
8$ ./result/bin/nixos-test-driver
9[...]
10>>>
11```
12
13::: {.note}
14By executing the test driver in this way,
15the VMs executed may gain network & Internet access via their backdoor control interface,
16typically recognized as `eth0`.
17:::
18
19You can then take any Python statement, e.g.
20
21```py
22>>> start_all()
23>>> test_script()
24>>> machine.succeed("touch /tmp/foo")
25>>> print(machine.succeed("pwd")) # Show stdout of command
26```
27
28The function `test_script` executes the entire test script and drops you
29back into the test driver command line upon its completion. This allows
30you to inspect the state of the VMs after the test (e.g. to debug the
31test script).
32
33## Shell access in interactive mode {#sec-nixos-test-shell-access}
34
35The function `<yourmachine>.shell_interact()` grants access to a shell running
36inside a virtual machine. To use it, replace `<yourmachine>` with the name of a
37virtual machine defined in the test, for example: `machine.shell_interact()`.
38Keep in mind that this shell may not display everything correctly as it is
39running within an interactive Python REPL, and logging output from the virtual
40machine may overwrite input and output from the guest shell:
41
42```py
43>>> machine.shell_interact()
44machine: Terminal is ready (there is no initial prompt):
45$ hostname
46machine
47```
48
49As an alternative, you can proxy the guest shell to a local TCP server by first
50starting a TCP server in a terminal using the command:
51
52```ShellSession
53$ socat 'READLINE,PROMPT=$ ' tcp-listen:4444,reuseaddr
54```
55
56In the terminal where the test driver is running, connect to this server by
57using:
58
59```py
60>>> machine.shell_interact("tcp:127.0.0.1:4444")
61```
62
63Once the connection is established, you can enter commands in the socat terminal
64where socat is running.
65
66## SSH Access for test machines {#sec-nixos-test-ssh-access}
67
68An SSH-based backdoor to log into machines can be enabled with
69
70```nix
71{
72 name = "…";
73 nodes.machines = {
74 # …
75 };
76 interactive.sshBackdoor.enable = true;
77}
78```
79
80::: {.warning}
81Make sure to only enable the backdoor for interactive tests
82(i.e. by using `interactive.sshBackdoor.enable`)! This is the only
83supported configuration.
84
85Running a test in a sandbox with this will fail because `/dev/vhost-vsock` isn't available
86in the sandbox.
87:::
88
89This creates a [vsock socket](https://man7.org/linux/man-pages/man7/vsock.7.html)
90for each VM to log in with SSH. This configures root login with an empty password.
91
92When the VMs get started interactively with the test-driver, it's possible to
93connect to `machine` with
94
95```
96$ ssh vsock/3 -o User=root
97```
98
99The socket numbers correspond to the node number of the test VM, but start
100at three instead of one because that's the lowest possible
101vsock number. The exact SSH commands are also printed out when starting
102`nixos-test-driver`.
103
104On non-NixOS systems you'll probably need to enable
105the SSH config from {manpage}`systemd-ssh-proxy(1)` yourself.
106
107If starting VM fails with an error like
108
109```
110qemu-system-x86_64: -device vhost-vsock-pci,guest-cid=3: vhost-vsock: unable to set guest cid: Address already in use
111```
112
113it means that the vsock numbers for the VMs are already in use. This can happen
114if another interactive test with SSH backdoor enabled is running on the machine.
115
116In that case, you need to assign another range of vsock numbers. You can pick another
117offset with
118
119```nix
120{
121 sshBackdoor = {
122 enable = true;
123 vsockOffset = 23542;
124 };
125}
126```
127
128## Port forwarding to NixOS test VMs {#sec-nixos-test-port-forwarding}
129
130If your test has only a single VM, you may use e.g.
131
132```ShellSession
133$ QEMU_NET_OPTS="hostfwd=tcp:127.0.0.1:2222-:22" ./result/bin/nixos-test-driver
134```
135
136to port-forward a port in the VM (here `22`) to the host machine (here port `2222`).
137
138This naturally does not work when multiple machines are involved,
139since a single port on the host cannot forward to multiple VMs.
140
141If the test defines multiple machines, you may opt to _temporarily_ set
142`virtualisation.forwardPorts` in the test definition for debugging.
143
144Such port forwardings connect via the VM's virtual network interface.
145Thus they cannot connect to ports that are only bound to the VM's
146loopback interface (`127.0.0.1`), and the VM's NixOS firewall
147must be configured to allow these connections.
148
149## Reuse VM state {#sec-nixos-test-reuse-vm-state}
150
151You can re-use the VM states coming from a previous run by setting the
152`--keep-vm-state` flag.
153
154```ShellSession
155$ ./result/bin/nixos-test-driver --keep-vm-state
156```
157
158The machine state is stored in the `$TMPDIR/vm-state-machinename`
159directory.
160
161## Interactive-only test configuration {#sec-nixos-test-interactive-configuration}
162
163The `.driverInteractive` attribute combines the regular test configuration with
164definitions from the [`interactive` submodule](#test-opt-interactive). This gives you
165a more usable, graphical, but slightly different configuration.
166
167You can add your own interactive-only test configuration by adding extra
168configuration to the [`interactive` submodule](#test-opt-interactive).
169
170To interactively run only the regular configuration, build the `<test>.driver` attribute
171instead, and call it with the flag `result/bin/nixos-test-driver --interactive`.