`nix-instantiate -A nixosTests.nixos-test-driver` fails with
error: A definition for option `virtualisation.host.pkgs' is not of type `An evaluation of Nixpkgs; the top level attribute set of packages'. Definition values:
- In `/home/ma27/Projects/nixpkgs-2/nixos/modules/virtualisation/qemu-vm.nix'
9p did resolve directory symlinks passed via
sharedDirectories.<item>.source, and new implementation doesn't.
Under the new virtiofs implementation, mounting symlinks manifests
failures only when trying to access the mount in the VM, with an error:
$ ls /mnt/my_shared_dir
ls: /mnt/my_shared_dir: Input/output error
Keep virtiofs for linux, but use 9p otherwise. This restores darwin
support - which is used both for `darwin.linux-builder` and `build-vm`
nixpkgs VMs.
This patch does not restore removed options: their utility is not
immediately clear to me, and restoring the options would complicate the
code for unclear gains. Hopefully, the reduced scope also makes it more
palatable for maintainers to accept this functionality back in.
Run transient port cleanup after ovsdb starts and before ovs-vswitchd
starts.
To cite ovs-ctl(8),
This is important on certain environments where some ports are
going to be recreated after reboot, but other ports need to be
persisted in the database.
Consumers (e.g. libvirt or ovn-kubernetes) may mark ports as transient
and expect these ports will be removed from ovsdb on new boot.
Note: this mimics upstream rhel systemd unit:
https://github.com/openvswitch/ovs/blob/main/rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service
Assisted-by: Codex gpt-5.6-sol high
Otherwise, if gc later decides to remove registration derivation from
its store, consequent reboots will point to a missing registration file.
(As of this patch, this is not fatal because registration service
failure doesn't fail builder boot; a later patch in the series makes
registration service required, making sure we never boot with db that is
not populated.)
The container tests generally don't need this, it seems to work fine
so far, and this could genuinely be useful in image-based deployments.
Why an error instead of inheriting the setting?
Containers do not and should not inherit a parent setting like this.
If a container declares requiring too much, that's the mistake.
If the host does not support a container's declared environment, that's
a host problem.
If the container inherits the setting from the parent, the container's
configuration is not respected.
Example of the error message:
nodes.machine.containers.web-noip requires a Nix daemon but the host does not provided it, as option nodes.machine.nix.daemon.enable is disabled
