similar to: [PATCH] launch: direct: Pass -enable-fips option if qemu supports it.

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

virtio-scsi has been supported in qemu since 2012, and it is superior in every respect to virtio-blk. There's no reason to still be using virtio-blk. virtio-scsi support was initially added in 2012 (commit 0c0a7d0d868d153adf0600189f771459e1068b0a). You can still use virtio-blk using the (deprecated) iface parameter, but don't do that in new code. --- lib/guestfs-internal.h | 1 -

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

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

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..f1fe92b 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19 +574,9 @@

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..e8450e1 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19

--- src/launch-direct.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index 6eaee63..c091732 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -491,7 +491,14 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) */ ADD_CMDLINE ("-no-hpet"); #endif - ADD_CMDLINE

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 +

--- src/launch-direct.c | 11 +++++++++++ src/launch-libvirt.c | 14 ++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/src/launch-direct.c b/src/launch-direct.c index d0af04d..52badc2 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -451,6 +451,17 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) ADD_CMDLINE ("-initrd"); ADD_CMDLINE (initrd);

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 function was kind of like debug(), except that it didn't check the g->verbose flag and it only worked in the library (it would crash if used after fork). It also wasn't very useful. The sort of boot analysis done by tests/qemu/boot-analysis.c means that timestamping (some) messages is even less interesting than before. Remove it and replace calls with debug() instead. ---

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),

On Mon, Apr 18, 2016 at 02:49:07PM +0200, Pino Toscano wrote: > 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

[Moving this thread over to the public mailing list] On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote: > On Friday 29 November 2013 18:53:38 you wrote: > > > > I'm marking options with NONE (not used at all), or M (used in > > > > master) and/or RH7 (used in rhel-7.0). > > > > > > > > > * -nographic > > > > >

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,

This option was removed from qemu for no apparent reason except to break existing consumers. It does the same as -no-user-config, added in May 2012, so use that instead. --- builder/test-console.sh | 2 +- common/qemuopts/qemuopts-tests.c | 6 +++--- common/qemuopts/qemuopts.c | 2 +- contrib/p2v/build-p2v-iso.sh | 2 +-

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,

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)

Hi Richard, I see this patch is included into libguestfs >= 1.26.6 & libguestfs >= 1.27.24. I feel that version is too high. Now RHEL 7.0 runs libguestfs-1.22.6, RHEL 6.6 alpha and 6.5 runs libguestfs-1.20.11. Is that possible to backport this patch, in order to make this problem fixed in RHEL 7.0, 6.6, and 6.5? Thanks & Best Regards Qin Zhao (赵钦) China System and Technology Lab,

On Monday 02 December 2013 09:09:44 Richard W.M. Jones wrote: > On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote: > > On Friday 29 November 2013 18:53:38 you wrote: > > > > > I'm marking options with NONE (not used at all), or M (used in > > > > > master) and/or RH7 (used in rhel-7.0). > > > > > > > > > > > *