This is to actually allow for the target machine to reboot, which could
come in handy for some VM tests in NixOps. Well, actually to be more
specific: We need it for the Hetzner NixOps backend test. :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
GRUB 2 doesn't want to boot off a LVM disk:
machine# installing the GRUB 2 boot loader on /dev/vda...
machine# Path `/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting.
machine# /nix/store/7yc535h1lim1a5gkhjb3fr6c8193dv8w-install-grub.pl: installation of GRUB on /dev/vda failed
In theory GRUB 2 supports booting from LVM, but we probably need to
generate the right grub.conf (see
https://wiki.archlinux.org/index.php/GRUB2#LVM).
http://hydra.nixos.org/build/2904680
two minutes on my laptop. Note that due to sparse allocation, raw
disks don't actually take up more space than qcow2 disks (and
they're temporary anyway).
svn path=/nixos/trunk/; revision=33746
nfsd, as suggested by the nfs-utils README.
Also, rather than relying on Upstart events (which have all sorts of
problems, especially if you have jobs that have multiple
dependencies), we know just let jobs start their on prerequisites.
That is, nfsd starts mountd in its preStart script; mountd starts
statd; statd starts portmap. Likewise, mountall starts statd to
ensure that it can mount NFS filesystems. This means that doing
something like "start nfsd" from the command line will Do The Right
Thing and start the dependencies of nfsd.
svn path=/nixos/trunk/; revision=33172
TCP port on the guest. Useful during testing (e.g. to access a web
server in the guest through a web browser on the host).
svn path=/nixos/trunk/; revision=26987
This has the advantage that it doesn't depend on networking being
up.
* Move common QEMU/KVM guest configuration to profiles/qemu-guest.nix.
svn path=/nixos/trunk/; revision=26421
so the startup synchronisation didn't work, causing spurious QEMU
failures ("Device 'vde' could not be initialized").
svn path=/nixos/trunk/; revision=26055
together into virtual networks. This has several advantages:
- It's more secure because the QEMU instances use Unix domain
sockets to talk to the switch.
- It doesn't depend on the host's network interfaces. (Local
multicast fails if there is no default gateway, so for instance it
fails if a laptop is not connected to any network.)
- VDE devices can be connected together to form arbitrary network
topologies.
- VDE has a "wirefilter" tool to emulate delays and packet loss,
which are useful for network testing.
svn path=/nixos/trunk/; revision=25526
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
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
