The guest agent now refuses to build unless being built for one of a
list of specific supported operating systems.
Co-authored-by: Will Cohen <willcohen@users.noreply.github.com>
There's no reason to have one copy of qemu-ga in $out and another in
$ga, and because we only applied remove-references-to to one of the
copies, it caused a collision when QEMU was used in a buildEnv.
This is redundant with QEMU commit a5804fcf7b ("9pfs: local: ignore
O_NOATIME if we don't have permissions"), included in QEMU since
5.1.0, which will retry opens without O_NOATIME if they fail with it.
According to the QEMU documentation, virtiofsd is supposed to be run
directly by users. It therefore makes sense to have it in bin/, so it
will be in PATH. Such a change wouldn't make sense upstream, because
it would then conflict with the virtiofsd package, which is generally
preferred if available. But in Nixpkgs, we don't have to worry about
that and can just make QEMU's virtiofsd a lower priority than the one
from the dedicated package.
[1]: https://qemu.readthedocs.io/en/latest/tools/virtiofsd.html
Fixes: https://github.com/NixOS/nixpkgs/issues/113172 ("QEmu: virtiofsd prone to be garbage collected.")
Fixes: https://github.com/NixOS/nixpkgs/pull/153007 ("nixos/libvirtd: add ${cfg.qemu.package}/libexec to PATH")
The qemu-ga binary is already moved to a separate
output but still depends on qemu, adding about
600MiB to it's closure.
The command "strings qemu-ga" reveals that something
like
/nix/store/bqgpvv5qrpb741swczqk3lrdm5gzaqx2-qemu-host-cpu-only-6.2.0/bin
is contained, causing this false positive. So use
remove-references-to to reduce the closure to about
600KiB.
these may not be reliable enough to enable by default, but enabling
them as a passthru may allow us to get a feel for which platforms
have trouble with them
QEMU now supports automatically detecting which audio drivers to
build, so we don't need to pass --audio-drv-list anymore.
pkgsMusl.qemu* doesn't build at the moment because of dependency
issues, but with a lot of hacks I was able to do enough of a build to
be confident the changes to patches etc. are correct for Musl.
This fixes the qemu-kvm wrapper we add for convenience
silently not using KVM, when the system would support it
by at least leaving an indication in the log that the build ran
slower because it ran without KVM.
KVM should only be considered abailable if /dev/kvm exists and
is read-writable by the user that is trying to launch it.
The previous check for existance only had the consequence that
on some Linux distributions running VMs with Nix's QEMU only worked
if KVM was NOT installed.
fixes#124371
It's better to fail to build if our version of Meson isn't compatible
with QEMU's, so we'll know something is wrong. Otherwise, we'll get
subtle breakages that only manifest at runtime, which I think might be
what happened in 9e403b19a1 ("qemu: 5.1.0 -> 5.2.0") to necessitate
autoPatchelfHook.
I dropped autoPatchelfHook because it got confused with the debug
objects, and I can't reproduce the pixman linker errors that caused it
to be introduced in #106988 ("qemu: 5.1.0 -> 5.2.0").
first patch fixes crash in 9p code that occasionally happens also in nixos tests
second patch fixes io errors from discards in aio io engine with virtio-scsi
Tested building qemu_kvm, qemu_full, and qemu_test on x86_64-linux.
Also tested booting a VM generated with nixos-rebuild build-vm.
I wasn't able to test building pkgsMusl.qemu_kvm, because of many
build failures in dependencies.
5e25995295 ("qemu: 2.6.1 -> 2.7.0") added this, because the QEMU
build failed without it. That's no longer the case, so we can bring
back stack protection.
Yuka