similar to: [PATCH] lib: direct: Remove support for virtio-blk as the default.

Allow the appliance / root filesystem to be placed on a virtual NVDIMM and accessed directly by the guest kernel (DAX). This requires corresponding changes in supermin. --- src/guestfs-internal.h | 1 + src/launch-direct.c | 68 ++++++++++++++++++++++++++++++++++++++++---------- src/launch.c | 8 +++++- 3 files changed, 63 insertions(+), 14 deletions(-) diff --git

When using the direct backend, you should see the result of testing the qemu binary for the availability of KVM: libguestfs: qemu KVM: enabled Thanks: Andrea Bologna. --- lib/guestfs-internal.h | 1 + lib/launch-direct.c | 40 +++++------------- lib/qemu.c | 94 +++++++++++++++++++++++++++++++++++++++++- 3 files changed, 105 insertions(+), 30 deletions(-) diff --git

On qemu 1.1.2: qemu-system-x86_64: -no-kvm-pit-reinjection: invalid option Thanks: josv @ IRC --- lib/launch-direct.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index efedf92..db9b9f3 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -414,10 +414,7 @@ launch_direct (guestfs_h *g, void *datav, const char *arg)

v2 -> v3: - Rebase on top of the other patches. Rich.

From: "Richard W.M. Jones" <rjones@redhat.com> AAVMF is an open source UEFI implementation for aarch64 based on OVMF. As aarch64 is heading for requiring UEFI even inside guests, if the AAVMF firmware is installed on the host, use it as a hint that we should boot the guest using AAVMF instead of the default "empty machine". Note this requires very recent AAVMF, libvirt,

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.

NOTE: not for upstream, yet. v1 -> v2: - Remove the dependency on enabling ACPI, since ACPI is now enabled all the time. Rich.

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

The drive used for the appliance is a raw (sparse) disk: specify that explicitly in its -drive qemu command line options, so qemu can skip the autodetection of its format and save a tiny bit of time. --- src/launch-direct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index ee0a855..8521e5a 100644 --- a/src/launch-direct.c +++

This commit uses -bios bios-fast.bin if available, which basically stops SeaBIOS from trying to do PCI probing during boot, which is a waste of time when using the -kernel option. v1 -> v2: - Rebase on top of Pino's work. This still has 3 dependencies: - The qemu memoization work (v2). - Support for '-L ?' in qemu:

Hi guys, During the last few weeks, I've been looking at how to use SPDK as QEMU's bootable rootfs disk. I managed to boot up a SPDK rootfs disk by using OVMF UEFI boot-loader. And in order to deploy the guest OS before start-up(which has a unrecognizable filesystem to the host), I have written a small patch for the libguestfs. It was based on Redhat's CentOS libguestfs-1.36.10 RPM,

Introduce a new struct version with few helper functions for it: this allows to "atomically" represent a version number, without different variables to be used and checked together. Add a initialization function from a libvirt-style version number, and apply it for the qemu and libvirt versions in the direct and libvirt backends. --- src/Makefile.am | 1 +

Currently we have an OCaml library for generating the qemu command line (used only by ‘virt-v2v -o qemu’). However we also generate a qemu command line in ‘lib/launch-direct.c’, and we might in future need to generate a ‘-readconfig’-compatible configuration file if we want to go beyond 10,000 drives for scalability testing. Therefore this patch series reimplements the qemu command line code as

This QEMU property is specific to x86/x86_64, so add it only on these architectures. --- lib/launch-direct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index bc43dcea2..3b848165c 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -519,8 +519,10 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) arg ("-rtc",

Previously we used (on arm): -M virt -machine accel=... After this change, we use: -machine virt,accel=... On x86 there is no change. The -M option is an abbreviation for -machine, and we can combine the two options together. (Qemu combines the two options internally, but it's more predictable if we do it ourselves). Upstream qemu has supported the -machine option for over 5 years, and in

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

--- lib/launch-direct.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index 9f85013f9..00cb25077 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -66,6 +66,7 @@ struct backend_direct_data { pid_t recoverypid; /* Recovery process PID. */ struct version qemu_version; /* qemu version (0 if

NOTE: Not for upstream, yet. This depends on 3 non-upstream patches. - The qemu rework in libguestfs, which in turn depends on what Pino is up to. - Support for '-L ?' in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02596 - Support for bios-fast.bin in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02408 This commit

Patches 1 & 2 were posted previously here: https://www.redhat.com/archives/libguestfs/2016-May/msg00134.html Patch 3 is a hack so I can test this using my own version of qemu (the `-L ?' stuff is not upstream). Patch 4 is where the real action takes place: Replace the caching of qemu features in blob-like files with a sqlite database. Probably the best way to approach this patch is to

Instead of forcing valgrind to be run when --enable-valgrind-daemon is passed to configure, enable it only when the backend setting "valgrind_daemon" is set. This allows developers to keep building with --enable-valgrind-daemon, which unconditionally adds valgrind in the appliance but using only when requested. When --enable-valgrind-daemon is not passed (typical for release builds),