Adds a new option to the virtualisation modules that enables specifying explicitly named network interfaces in QEMU VMs.
The existing `virtualisation.vlans` option is still supported for cases where the name of the network interface is irrelevant.
Calling `eval-config.nix` without a `system` from a Nix flake fails with
`error: attribute 'currentSystem' missing` since #230523. Setting
`system = null` removes the use of `currentSystem` and instead uses the
value from the `nixpkgs` module.
Context summary:
'vma create' can't otherwise write to tmpfs such as /dev/shm.
This is important when used from non-nixos machines which may
have /build as tmpfs.
VMA is Proxmox's virtual machine image format that wraps QEMU images,
augmenting these with proxmox-specific configuration file.
proxmox-image.nix uses the VMA tool to create vma image files.
The VMA tool exists as a patchset ontop of QEMU.
VMA writes its output with open() and O_DIRECT flag.
O_DIRECT does not work on Linux tmpfs [1]. Thus:
$ vma create ~/output.vma ... # works, assuming home isn't tmpfs.
$ vma create /dev/shm/output.vma ... # fails since /dev/shm is tmpfs
Failure results in assert(*errp == NULL).
O_DIRECT is a cache performance hint.
But it currently blocks our usage of nixos-generate -f proxmox from
Non-NixOS hosts and Docker.
The patch here simply removes O_DIRECT:
vma-writer.c later performs memalign due to O_DIRECT, but this is
safe to do with or without O_DIRECT.
Ideally, this should be fixed in upstream Proxmox: Perhaps by falling
back to open without O_DIRECT.
Another attempt to fix this SIGABRT is [2], which writes the vma file
directory to $out/ folder -- however that may still be tmpfs mounted
which it is in our case.
[1] https://lore.kernel.org/lkml/45A29EC2.8020502@tmr.com/t/
[2] https://github.com/NixOS/nixpkgs/pull/224282
`useEFIBoot` is somewhat misleading, but we should make it possible to
enable UEFI environment / firmware without buying into a bootloader.
This makes it possible.
Previously, it was possible to run with a tmpfs / with
`virtualisation.diskImage = null;`, this was likely broken by my changes
in 4b4e4c3ef9.
It is reintroduced by disabling properly the bootloader for now, as it
is complicated to make it work with.
Now that `useBootLoader` produces a full system image, moving disk
images can be slow because they have a full Nix store in them.
It does not make sense to keep the 9p mountpoint to shadow the
/nix/store of the VM.
We disable it if we have `useBootLoader` and introduce an option for
easy overrides.
This option has been introduced in 678eed323f without realizing there was this
PR inflight, unfortunately, it collide with what this PR does and make
it irrelevant.
Therefore, I remove it here.
