What would you think about also adding an option in the hypervGuest section which would trigger boot.kernel.sysctl."vm.overcommit_memory" = "1";? Per my notes on nixos-hardware, I had to do this to avoid a problem with nix-env -i running out of memory (see also NixOS/nix#421). I imagine it could be disabled by default, but adding it there might make it easier for people to make their own decision.

Sorry I'll not be able to test this, but I uninstalled HyperV from my Windows notebook in the end, as I grew tired of trying to use NixOS that way (the machine had too little memory to do this comfortably while also "living normally" with a memory-hungry web browser on Windows).

Would you mind also editing the relevant nixos-hardware "guide" to take into account your simplifications after this PR hopefully gets merged?

As to your comment about BIOS vs. UEFI, I'm not even sure if my machine is BIOS- or UEFI-based... so won't be able to discuss this more too, I'm afraid... I just dumped into nixos-hardware whatever I found helped me, in hope that other people might find it useful too...

The memory issue was addressed in NixOS/nix@2825e05 so the overcommit workaround should no longer be needed - this isn't specific to hyperv.

I'm not even sure if my machine is BIOS- or UEFI-based

It's not about the host machine - the VM can be created as gen1 (BIOS) or gen2 (UEFI).

With the mentioned PR, there really shouldn't be anything needed to boot on HyperV - it should just work. Then you guide could cover file sharing as well as the gen1/gen2 distinction for the boot loader.

Are installer changes too late for 18.09 @vcunat and @samueldr ?

This seems safe to affect hyper-v only, so I'd not block that, if it gets some confidence through review, testing, etc. (Even if to be merged after official release.)

This PR is a cleanup of the configuration we have had running for customers in production for months so it should be safe. I'll deploy this exact configuration and merge if all OK.