similar to: [PATCH] launch: rework handling of --enable-valgrind-daemon

If you've ever tried to use this option, you'll know that it didn't work well. It broke random things (probably RHBZ#1020216, definitely RHBZ#1023630), and caused random failures generally, while often not actually failing when valgrind itself found problems. This does not remove the guestfs_internal_exit API. That will instead be modified in a future commit. ---

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

From: "Richard W.M. Jones" <rjones at redhat.com> This commit allows you to run the daemon under valgrind. You have to enable it at configure time: ./configure --enable-valgrind-daemon This should *not* be done for production builds. When this feature is enabled, valgrind is added to the appliance and the daemon is run under valgrind. Log messages from valgrind are passed

Previously posted here: https://www.redhat.com/archives/libguestfs/2015-June/msg00266.html Rich.

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 -

This is just code refactoring. --- src/launch.c | 172 +++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 109 insertions(+), 63 deletions(-) diff --git a/src/launch.c b/src/launch.c index 46d7ab9..84d5e82 100644 --- a/src/launch.c +++ b/src/launch.c @@ -293,9 +293,7 @@ guestfs_impl_config (guestfs_h *g, #endif #if defined(__aarch64__) -#define EARLYPRINTK "

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

On Tue, Feb 02, 2016 at 03:27:39PM +0100, Pino Toscano wrote: > Introduce an internal helper to create paths for sockets; will be useful > for changing later the logic for placing sockets. > --- > src/guestfs-internal.h | 1 + > src/launch-direct.c | 4 +++- > src/launch-libvirt.c | 10 ++++++---- > src/launch.c | 15 +++++++++++++++ > 4 files changed, 25

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. ---

From: "Richard W.M. Jones" <rjones at redhat.com> This allows custom parameters to modify parameters added by libguestfs, eg. by doing: -set drive.hd0.file=rbd:foo/bar Thanks: infernix @ #libguestfs --- src/launch-appliance.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/src/launch-appliance.c b/src/launch-appliance.c

The quiet option suppresses kernel messages. On my laptop it improves appliance boot times by about 40% (3.5s -> 2.5s). The emulated UART is slow and has a fixed, small FIFO (16 bytes). But it has the advantage of being a simple ISA device which is available very early in boot, thus enabling us to diagnose early boot problems. So the aim is to reduce our usage of this UART on fast paths. Of

The API for UNIX sockets limits the path to a static size (usually 104 or 108 characters, NULL included), which is internally represented as UNIX_PATH_MAX. If the temporary directory set is long enough (e.g. when running tools as uninstalled, using "run") then these socket paths get trucated, if not even cause failures when binding the sockets. Introduce a new internal API to create

Just code motion. In theory we could also add earlyprintk=ttyS0,115200 on x86, but I cannot get it to work. --- src/launch.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/launch.c b/src/launch.c index 074ac6f..886041a 100644 --- a/src/launch.c +++ b/src/launch.c @@ -303,6 +303,12 @@ guestfs_impl_config (guestfs_h *g, #define SERIAL_CONSOLE

From: "Richard W.M. Jones" <rjones at redhat.com> Check /sbin, /usr/sbin, /bin and /usr/bin to ensure that neither the directory nor the parent (eg. /usr) is a symlink, and use this directory for the virtual directory used to store guestfsd in the appliance. --- appliance/Makefile.am | 9 +++++---- configure.ac | 20 ++++++++++++++++++++ 2 files changed, 25

By passing root=UUID=... to supermin, we make the appliance boot process less sensitive to the non-deterministic process of scanning SCSI disks (of which much more to come). This patch should be tested alongside the supermin patch posted here: https://www.redhat.com/archives/libguestfs/2017-April/msg00174.html which in turn requires this supermin patch series:

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 patch series lets you run the daemon under valgrind. Many errors were found and fixed. With the complete series applied, valgrind doesn't show any errors.

On Fri, Jan 29, 2016 at 07:25:30PM +0100, Pino Toscano wrote: > The API for UNIX sockets limits the path to a static size (usually 104 > or 108 characters, NULL included), which is internally represented as > UNIX_PATH_MAX. If the temporary directory set is long enough (e.g. > when running tools as uninstalled, using "run") then these socket paths > get trucated, if not

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,

EDD (https://en.wikipedia.org/wiki/Enhanced_Disk_Drive) is a BIOS INT 13h subcall for communicating the extended size of the boot disk over 8GB to the OS. Since libguestfs doesn't use a boot disk, and the appliance disk is limited to 4GB, and we use virtio-scsi, this is all useless. EDD is also broken currently on RHEL 7.3, see: https://bugzilla.redhat.com/show_bug.cgi?id=1404287 Also the