This adds a new function in vmTools, called runInWindowsVM, which allows
to run a derivation within a Windows + Cygwin environment.
To use it, you need to pass a Windows ISO and product key, for example:
------------------------------------------------------
vmTools.runInWindowsVM (stdenv.mkDerivation {
name = "hello-from-windows";
windowsImage = {
isoFile = /path/to/windows/image.iso;
productKey = "ABCDE-FGHIJ-KLMNO-PQRST-UVWXY";
};
buildCommand = ''
echo 'Look, I am running inside Windoze!'
uname -a > "$out"
'';
})
------------------------------------------------------
The derivation is then run within a special build process, which roughly
does something like this:
____________
| |
| controller |
|____________|
/ | \
_________ / ____|____ \___________ _______
| | | | | | | |
| install | -> | suspend | -> | suspended | -> | build |
|_________| |_________| |___________| |_______|
There are three steps necessary to produce the builder, which in the end
is just a suspended Windows VM, running Cygwin and OpenSSH.
Those steps are essentially:
* install: Install the base Windows VM with Cygwin and OpenSSH.
* suspend: Run the installed VM and dump the memory into a state file.
* suspended: Resume from the state file and execute the build.
Every build is based on the "suspended" step, which throws away all
changes except to the resulting output store path(s).
All of these steps are based on the controller, which is described in
greater detail in commit 276b72fb93d60ae0e59088ea0e0029da87e6f31c.
The reason I'm merging this right in is because it actually adds a
feature that doesn't break existing functionality and only hooks into
vmTools with a single line.
To the contrary it even duplicates a bit of the code from vmTools, which
might be a good start for refactoring. I didn't do that within that
branch, because it otherwise *could* break existing functionality - VM
tests in particular.
Also, this implementation currently *only* supports Windows XP, because
the implementation was originally made for building a Software where the
majority of the users are using Windows XP and we need to do extensive
testing on that platform.
However, adding support for more recent versions is rather trivial. All
there needs to be done is adding a new unattended installation config in
unattended-image.nix.
Also update 64bit setup.ini and check whether we have a 64 bit stdenv in
order to choose the proper Cygwin version. Otherwise we now have the
setup.ini for 32bit available as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far, the VMs have always been using the native architecture, because
it was reimporting <nixpkgs> several times. Now, we propagate a list of
packages down to all sub-imports, which not only makes clearer which
dependencies a part actually has, but also will make it easier in case
we want to refactor those parts to use callPackage.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This now isolates the vmTools integration from the bootstrap process and
thus removes our fixed Windows ISO and product key. The latter can now
be provided by an attribute "windowsImage" to runInWindowsVM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the last item that was missing to get a fully working
runInWindowsVM function. Apart from checking exit codes, we also now
have preVM/postVM hooks which we can use to write arbitrary constructs
around this architecture, without the need to worry about specific
details.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This function is quite similar to runInLinuxVM, but also ensures that
the builder is run decoupled of the Nix store and using the userland
inside the VM.
We're now picking up the environment variables saved in the previous
commit.
The reason we suppress all errors from the source operation is that it
would emit a ton of errors because we're trying to set read-only
variables.
Also, detecting whether the origBuilder is using the default builder
from the stdenv is currently a bit of a workaround until we have a
specialized pseudo-cross-stdenv someday in the future[TM].
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Later, when we start the actual builder, we're going to restore those
environment variables. We're using "(set; declare -p)", here, because
the former is just printing _all_ environment variables, even those not
supported, and the latter only lists specifically declared variables,
which also encludes exports.
The "declare -p" command also emits those variables in a format similar
to the "export" command.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is mainly to make it easier to quickly change mappings, without
making room for errors such as typos.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cygwin initializes mounts on _every_ login via SSH and doesn't keep them
consistently like on Unix systems, that's why we need to also add fstab
entries for the bind mounts to the store and xchg shares.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
