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
console. This uses the `sendkey' command in the QEMU monitor.
* For the block/unblock primitives, use the `set_link' command in the
QEMU monitor.
svn path=/nixos/trunk/; revision=19854
it special commands such as "screendump", "sendkey" and so on.
* Take screenshots using the "screendump" command. This has the
advantage over "scrot" that it also supports taking a picture of the
console, and is not affected by weird X visuals.
svn path=/nixos/trunk/; revision=19837
its default behaviour is to stop the emulator (i.e. suspend the VM).
For automated tests, this is bad, because is makes the VM appear to
hang without any error message. The "werror=report" flag causes
QEMU to report the problem to the VM. As a side effect QEMU exits
very elegantly:
[ 2.308668] end_request: I/O error, dev vda, sector 534400
[ 2.309611] Buffer I/O error on device vda, logical block 66800
...
*** glibc detected *** /nix/store/yhngqrww53j0aw7z7v4bv948x5g5fc3d-qemu-kvm-0.12.1.2/bin/qemu-system-x86_64: double free or corruption (!prev): 0x08e3e040 ***
Aborted
So I guess we now depend on a bug in QEMU :-)
svn path=/nixos/trunk/; revision=19703
