Peter Maydell <peter.mayd...@linaro.org> writes: > On Tue, 10 Jan 2023 at 16:26, Markus Armbruster <arm...@redhat.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> writes: >> > Does it actually require '.' on the PATH, or does it just want >> > a qemu-img binary on the PATH? (eg your distro one in /usr/bin). >> > I don't have '.' on my PATH and it works for me. >> >> Do we want to use qemu-img, qemu-system-x86_64 and so forth from PATH, >> or the one in the build tree? > > There's no guarantee there is one in the build tree at all. > I usually use these like > (cd build && ../configure) > make -C build vm-build-openbsd > > in which case it doesn't need to build anything in the build > tree at all (neither qemu-system-x86_64 nor qemu-img). > > It's nice to be able to do "test this build on *BSD" with > a known-good QEMU running the VM rather than having the > code-under-test affecting both the outer QEMU and the > build-and-make-check running inside the VM.
True. >> The former could well be old, which feels like a potential source of >> problems. > > In practice we only use it for very simple operations > ("create a qcow2 image" and "resize this qcow2 file"), > so using the distro qemu-img has never been an issue for me. > > I think I have in the past run into problems because the > system's qemu-system-x86_64 was super-old, but it was easy > to just build a known-good QEMU version and put that on > the PATH. (And now that system has had a host distro > upgrade, so I have gone back to using the system binary.) I since came to understand this line in output of vm-help: QEMU_LOCAL=1 - Use QEMU binary local to this build. So the intent appears to be "use (presumably known-good) QEMU tooling from $PATH by default, pass QEMU_LOCAL=1 to use the build tree instead, and pass QEMU=... QEMU_IMG=... QEMU_CONFIG=... when you need even more control." Thanks again!