This ensures that the intermediate machine is shut down only after the
migration has finished writing the memory dump to disk, to ensure we
don't end up with empty state files depending on how fast the migration
finished before we actually shut down the VM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This ensures that the builder isn't waiting forever if the Windows VM
drops dead while we're waiting for the controller VM to signal that a
particular command has been executed on the Windows VM. It won't ever
happen in such cases so it doesn't make sense to wait for the timeout.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far, we determined this based on stdenv.is64bit, but there are cases
where you want to run/build a 32bit program on a 64 bit Windows.
This is now possible, by passing windowsImage.arch = "i686" | "x86_64"
to runInWindowsVM. Based an what was passed, the corresponding Cygwin
packages and setup.exe are bootstrapped.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Another very annoying part. Unfortunately, the only option we might have
here is to include it in nixpkgs or maybe make a fixed Hash on the
result of the closure fetcher.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As the official Cygwin setup binary download doesn't come in snapshots
or even versioned, the fetchurl of setup.exe will frequently fail, which
in turn will annoy us as hell (or at least me).
One warning though: The fetchurl is currently broken and the cross-build
might not work yet for example on mingw32 (mingw-w64 branch on its way),
but the upstream URL has already changed and the new version contains a
bug (not yet tracked down) which breaks our Windows bootstrap process.
So to conclude: If it's already broken, make it at least "less broken".
"Not broken" is coming soon with the merge of the mingw-w64 branch.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Coincidentally, even with this typo, most tests work anyway, so I didn't
notice it in the first place.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
We now map all guest accounts to the root user, because in the end the
permissions of the current user boil down to the build user of the Nix
builder of the host. That way it's not possible to gain more permissions
at all and just makes the VM communication a lot easier.
However, setting "writable" to yes instead of "read only" to no doesn't
change anything here, I just found it to be clearer.
Also, we now no longer need to have a "nobody" user.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is done by putting the non-initrd /nix/store into a subdirectory,
which we then chroot to and pass along the SSH command.
Also, we now collect the exit code after the chroot command and power
off the VM thereafter, because the store is no longer shadowed and we
have still access to the busybox inside the initrd.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should trim down possible dependencies on the base installation and
hereby reduce the need for reinstallation of the damn VM to only changes
that affect the Windows installation and the base Cygwin + OpenSSH
setup.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This now finally introduces our xchg share and also uses it for
exchanging state while suspending a VM. However, accessing the _real_
Nix store still isn't possible because we're shadowing the directory in
the initrd.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now we're doing this at the point where we're saving the VM state.
Unfortunately it's not quite right, because the controller VM is shut
down _before_ we're saving the state, so the share gets disconnected
despite autodisconnect being deactivated during setup.
We can get around this issue by finally introducing the xchg share,
which is the last item to be implemented before we can merge to master.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Security-wise it's not a big issue because we're still sandboxed, but I
really don't want to write something like \\\\\\\\192.168.0.2\\\\share
in order to set up network shares.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're going to do this during the suspendedVM phase, so we're able to
more easily change the shares without reinstalling the whole VM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This could possibly cause flapping whenever qemu is too fast in starting
up. As we are running with the shell's -e flag, the socat check also
ensures that the VDE switch is properly started and causes the whole
build to fail, should it not start up within 20 seconds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
These stages are in particular:
* Install of the bare Windows VM with Cygwin and shut down.
* Boot up the same VM again without the installation media and dump the
VMs memory to state.gz.
* Resume from state.gz and build whatever we want to build.
Every single stage involves a new "controller", which is more like an
abstraction on the Nix side that constructs the madness described in
276b72fb93.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is kinda stupid to do every little time the file is automatically
regenerated upstream. But let's see how often that happens and whether
it will become a major annoyance or not, and if yes, we might be forced
to include it in our source tree.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This SSH key is specifically only for accessing the installed Cygwin
within the Windows VM, so we only need to expose the private key. Yes,
you heard right, the private key. It's not security-relevant because the
machine is completely read-only, only exposed to the filesystem and
networking is not available.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
