Otherwise, starting this daemon fails with the message
```
virtchd[3484224]: Initialization of mandatory cloud-hypervisor state driver skipped
virtchd[3484224]: Driver state initialization failed
```
Fixes #167850
Move all `virtualisation.libvirtd.qemu*` options to a
`virtualisation.libvirtd.qemu` submodule.
Also for consistency, add `virtualisation.libvirtd.qemu.swtpm.package`
(only new option during this refactor.)
iptables is currently defined in `all-packages.nix` to be
iptables-compat. That package does however not contain `ethertypes`.
Only `iptables-nftables-compat` contains this file so the symlink
dangles.
At the moment, it's not possible to override the libvirtd package used
without supplying a nixpkgs overlay. Adding a package option makes
libvirtd more consistent and allows enabling e.g. ceph and iSCSI support
more easily.
This dependency has been added in 65eae4d, when NixOS switched to
systemd, as a substitute for the previous udevtrigger and hasn't been
touched since. It's probably unneeded as the upstream unit[1] doesn't
do it and I haven't found any mention of any problem in NixOS or the
upstream issue trackers.
[1]: https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/libvirtd.service.in
Per upstream:
> libvirtd-tcp.socket - the unit file corresponding to the TCP 16509
> port for non-TLS remote access. This socket should not be configured
> to start on boot until the administrator has configured a suitable
> authentication mechanism.
Systemd dependencies for scripted mode
were refactored according to analysis in #34586.
networking.vswitches can now be used with systemd-networkd,
although they are not supported by the daemon, a nixos receipe
creates the switch and attached required interfaces (just like
the scripted version).
Vlans and internal interfaces are implemented following the
template format i.e. each interface is
described using an attributeSet (vlan and type at the moment).
If vlan is present, then interface is added to the vswitch with
given tag (access mode). Type internal enabled vswitch to create
interfaces (see openvswitch docs).
Added configuration for configuring supported openFlow version on
the vswitch
This commit is a split from the original PR #35127.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
This adds a new ``onBoot`` option that allows specifying the action taken on
guests when the host boots. Specifying "start" ensures all guests that were
running prior to shutdown are started, regardless of their autostart settings.
Specifying "ignore" will make libvirtd ignore such guests. Any guest marked as
autostart will still be automatically started by libvirtd.
`services.virtualisation.libvirtd.onShutdown` was previously unused.
While suspending a domain on host shutdown is the default, this commit
makes it so domains can be shut down, also.
Currently libvirt requires two qemu derivations: qemu and qemu_kvm which is just a truncated version of qemu (defined as qemu.override { hostCpuOnly = true; }).
This patch exposes an option virtualisation.libvirtd.qemuPackage which allows to choose which package to use:
* pkgs.qemu_kvm if all your guests have the same CPU as host, or
* pkgs.qemu which allows to emulate alien architectures (for example ARMV7L on X86_64), or
* a custom derivation
virtualisation.libvirtd.enableKVM option is vague and could be deprecate in favor of virtualisation.libvirtd.qemuPackage, anyway it does allow to enable/disable kvm.
Although it is quite safe to restart ```libvirtd``` when there are only ```qemu``` machines, in case if there are ```libvirt_lxc``` containers, a restart may result in putting the whole system into an odd state: the containers go on running but the new ```libvirtd``` daemons do not see them.
Use xmlstarlet to update the OVMF path on each startup, like we do for
<emulator>...qemu-kvm</emulator>.
A libvirt domain using UEFI cannot start if the OVMF path is garbage
collected/missing.
Instead of grep and sed, which is brittle.
(I don't know how to preserve the comment we currently add to say that
this line is auto-updated. But I don't think it adds much value, so I'm
not spending any effort on it.)
OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).
Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,
Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary. As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree). In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.
Fixes https://github.com/NixOS/nixpkgs/issues/25854
Closes https://github.com/NixOS/nixpkgs/pull/25855
Modifies libvirt package to search for configs in /var/lib and changes
libvirtd service to copy the default configs to the new location.
This enables the user to change e.g. the networking configuration with
virsh or virt-manager and keep those settings.
