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.
This fixes the issue when the LXC emulator binary is garbage collected
and breaks libvirtd containers, because libvirtd XML file still refers
to GC'ed store path.
We already have a fix for QEMU, this commit extends the fix to cover LXC
too.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
libvirtd puts the full path of the emulator binary in the machine config
file. But this path can unfortunately be garbage collected while still
being used by the virtual machine. Then this happens:
Error starting domain: Cannot check QEMU binary /nix/store/z5c2xzk9x0pj6x511w0w4gy9xl5wljxy-qemu-1.5.2-x86-only/bin/qemu-kvm: No such file or directory
Fix by updating the emulator path on each service startup to something
valid (re-scan $PATH).
Fixes this:
Nov 09 16:18:54 nixos-laptop systemd[1]: Starting Libvirt Virtual Machine Management Daemon...
Nov 09 16:18:54 nixos-laptop dnsmasq[15809]: read /etc/hosts - 2 addresses
Nov 09 16:18:54 nixos-laptop dnsmasq[15809]: failed to load names from /var/lib/libvirt/dnsmasq/default.addnhosts: Permission denied
Nov 09 16:18:54 nixos-laptop dnsmasq[15809]: cannot read /var/lib/libvirt/dnsmasq/default.hostsfile: Permission denied
Nov 09 16:18:55 nixos-laptop systemd[1]: Started Libvirt Virtual Machine Management Daemon.
I don't understand the reason for the original 700 permission bits.
Apparently read-access is needed and Ubuntu also use 755 perms.
Use "chmod" instead of "mkdir -m" to set permissions because mkdir doesn't
modify permissions on existing directories.
Virsh/virt-manager uses ssh to connect to master, there it expects openbsd netcat(which
has support for unix sockets) to be avalible, to make a tunnel.
Close #1087.
