is now made available in the interactive test driver. For instance,
you can do
$ nix-build tests/ -A quake3.driver
$ ./result/bin/nixos-test-driver
> eval $ENV{'testScript'};
... see VMs + X11 + Quake get started, bots running around ...
>
So after this you can run commands interactively on the VMs in the
state they were in after the conclusion of the test script.
svn path=/nixos/trunk/; revision=25158
interactively on a network specification. For instance:
$ nix-build tests/ -A quake3.driver
$ ./result/bin/nixos-test-driver
> startAll;
client1: starting vm
client1: QEMU running (pid 14971)
server: starting vm
server: QEMU running (pid 14982)
...
> $client1->execute("quake3 ...");
* Use the GNU readline library in interactive mode.
svn path=/nixos/trunk/; revision=25156
It turns out that all network interfaces in all VMs had the same
Ethernet address (52:54:00:12:34:56) because we didn't specify any
with the macaddr=... option. This can obviously lead to great
confusion. For instance, when a router forwards a packet, it can
actually end up sending the packet to itself because the target
machine has the same Ethernet address (causing a loop until the TTL
expires), while the target *also* receives the packet. It's amazing
anything worked at all, really.
So now we just set the Ethernet addresses to 52:54:00:12:<virtual
network number>:<machine number>.
svn path=/nixos/trunk/; revision=25020
which NixOS should be built. This is useful in NixOS network
specifications, because it allows machines in the network to have
different types, e.g.,
{
machine1 =
{ config, pkgs, ... }:
{ nixpkgs.system = "i686-linux";
... other config ...
};
machine2 =
{ config, pkgs, ... }:
{ nixpkgs.system = "x86_64-linux";
... other config ...
};
}
It can also be useful in distributed NixOS tests.
svn path=/nixos/trunk/; revision=24823
- Added a backdoor option to the interactive run-vms script. This allows me to intergrate the virtual network approach with Disnix
- Small documentation fixes
Some explanation:
The nixos-build-vms command line tool can be used to build a virtual network of a network.nix specification.
For example, a network configuration (network.nix) could look like this:
{
test1 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
...
};
test2 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
services.xserver.enable = true;
}
;
}
By typing the following instruction:
$ nixos-build-vms -n network.nix
a virtual network is built, which can be started by typing:
$ ./result/bin/run-vms
It is also possible to enable a backdoor. In this case *.socket files are stored in the current directory
which can be used by the end-user to invoke remote instruction on a VM in the network through a Unix
domain socket.
For example by building the network with the following instructions:
$ nixos-build-vms -n network.nix --use-backdoor
and launching the virtual network:
$ ./result/bin/run-vms
You can find two socket files in your current directory, namely: test1.socket and test2.socket.
These Unix domain sockets can be used to remotely administer the test1 and test2 machine
in the virtual network.
For example by running:
$ socat ./test1.socket stdio
ls /root
You can retrieve the contents of the /root directory of the virtual machine with identifier test1
svn path=/nixos/trunk/; revision=24410
guest connect to a Unix domain socket on the host rather than the
other way around. The former is a QEMU feature (guestfwd to a
socket) while the latter requires a patch (which we can now get rid
of).
svn path=/nixos/branches/boot-order/; revision=22331
or Google Earth) on 64-bit NixOS on NVIDIA hardware. The 32-bit
OpenGL library is symlinked from /var/run/opengl-driver-32, which is
added to the LD_LIBRARY_PATH so that 32-bit binaries can find it.
svn path=/nixos/trunk/; revision=22062
function argument, so that the test script can refer to computed
values such as the assigned IP addresses of the virtual machines.
svn path=/nixos/trunk/; revision=21939
machine can now declare an option `virtualisation.vlans' that causes
it to have network interfaces connected to each listed virtual
network. For instance,
virtualisation.vlans = [ 1 2 ];
causes the machine to have two interfaces (in addition to eth0, used
by the test driver to control the machine): eth1 connected to
network 1 with IP address 192.168.1.<i>, and eth2 connected to
network 2 with address 192.168.2.<i> (where <i> is the index of the
machine in the `nodes' attribute set). On the other hand,
virtualisation.vlans = [ 2 ];
causes the machine to only have an eth1 connected to network 2 with
address 192.168.2.<i>. So each virtual network <n> is assigned the
IP range 192.168.<n>.0/24.
Each virtual network is implemented using a separate multicast
address on the host, so guests really cannot talk to networks to
which they are not connected.
* Added a simple NAT test to demonstrate this.
* Added an option `virtualisation.qemu.options' to specify QEMU
command-line options. Used to factor out some commonality between
the test driver script and the interactive test script.
svn path=/nixos/trunk/; revision=21928
What I want with this derivation is to allow the sheevaplug nixos to
build a tarball with all the needed files to boot. Then, this can be
unpacked into an SD card, or into a NFS/TFTP server, and then the
user can boot the system with help of the uboot console.
By now, I have only tried to build the tarball in a PC, in order
to develop the nix expressions quicker.
There is nothing written specialy for the Sheevaplug in all this,
by now.
svn path=/nixos/trunk/; revision=20035
