modules/virtualisation: add shared options, merge various diskSize options

[phaer]

Description of changes

Take two of #339535, with a fix that should hopefully prevent us from blocking a channel or breaking anything else this time.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[phaer]

@ofborg test installer

[phaer]

Hm.. the installer tests failing according to ofborg seem to run fine locally and as it's a timeout, maybe hydra is overburdened or so? 🤔

nom-build -A nixosTests.installer.bcachefsSimple -A nixosTests.installer.clevisBcachefs -A nixosTests needs almost 8 minutes on a rather beefy server, doing nothing else. But it finishes successfully.

[phaer]

@ofborg test installer

[phaer]

Tests are still failing, due to low disk space according to ofborg.

I ran all of the installer tests locally and they were successful, so I am suspecting this might be the hydra builder running low on disk space or so?

[zimbatm]

@arianvp do you want to test those changes for the AWS AMIs before we merge?

[arianvp]

I can look at this after the 24th. But if other make-disk-image based images work i expect the aws one to work as well

[phaer]

@ofborg test installer.clevisBcachefs

[roberth]

Why is this an attrset containing a module instead of just a module? Couldn't this just be a normal module?

[phaer]

The idea was to be able to pick options from virtualisation-options.nix as needed per module - similar to how lib/nixos/systemd-unit-options.nix.

I then switched to an attrset of modules instead of options to be able to use assertions. Suppose we could move those to the options check function if an attrset of options would be preferable for some reasons.

[roberth]

Assertions will work just fine. They're part of the module fixpoint like any other option, so module composition is all you need - no need to go around the module system.

[zimbatm]

Let's merge this so it doesn't diverge.

The main design decision of this PR is to introduce a shared diskSize attribute between various disk outputs. This makes sense because each disk output requires a new evaluation (it wouldn't make sense to import multiple profiles with conflicting target settings in the same evaluation).

[phaer]

I am on vacation this week, so from my point of few it doesn't hurt to wait a bit with a merge and let @arianvp check that it doesn't break the aws image

[endgame]

In response to a request for help on Matrix, I built the disk image following the instructions at http://jackkelly.name/blog/archives/2020/08/30/building_and_importing_nixos_amis_on_ec2/index.html, uploaded it to S3, imported it to an EBS snapshot, created an AMI from it, launched an instance from the AMI, and SSH'd into it as root. Does that help?

I did not provide any explicit NixOS configuration.

[roberth]

The idea is great, but let's just use a module file and avoid the unnecessary bells and whistles. Other than that LGTM.