nixpkgs/pkgs/build-support/vm/windows/default.nix

46 lines
1.3 KiB
Nix
Raw Normal View History

2017-01-15 12:44:52 +00:00
#note: the hardcoded /bin/sh is required for the VM's cygwin shell
pkgs:
vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 02:47:57 +00:00
let
bootstrapper = import ./bootstrap.nix {
inherit (pkgs) stdenv vmTools writeScript writeText runCommand makeInitrd;
inherit (pkgs) coreutils dosfstools gzip mtools netcat-gnu openssh qemu samba;
inherit (pkgs) socat vde2 fetchurl python perl cdrkit pathsFromGraph;
inherit (pkgs) gnugrep;
};
vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 02:47:57 +00:00
builder = ''
source /tmp/xchg/saved-env 2> /dev/null || true
export NIX_STORE=/nix/store
export NIX_BUILD_TOP=/tmp
export TMPDIR=/tmp
export PATH=/empty
cd "$NIX_BUILD_TOP"
exec $origBuilder $origArgs
'';
in {
runInWindowsVM = drv: let
in pkgs.lib.overrideDerivation drv (attrs: let
bootstrap = bootstrapper attrs.windowsImage;
in {
requiredSystemFeatures = [ "kvm" ];
builder = "${pkgs.stdenv.shell}";
args = ["-e" (bootstrap.resumeAndRun builder)];
windowsImage = bootstrap.suspendedVM;
origArgs = attrs.args;
origBuilder = if attrs.builder == attrs.stdenv.shell
then "/bin/sh"
else attrs.builder;
postHook = ''
PATH=/usr/bin:/bin:/usr/sbin:/sbin
SHELL=/bin/sh
eval "$origPostHook"
vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 02:47:57 +00:00
'';
origPostHook = attrs.postHook or "";
fixupPhase = ":";
});
}