search for: launch_t

...ta->recoverypid > 0) waitpid (data->recoverypid, NULL, 0); + if (data->pid > 0) guestfs_int_waitpid_noerror (data->pid); + if (data->recoverypid > 0) guestfs_int_waitpid_noerror (data->recoverypid); data->pid = 0; data->recoverypid = 0; memset (&g->launch_t, 0, sizeof g->launch_t); @@ -1484,16 +1483,14 @@ shutdown_direct (guestfs_h *g, void *datav, int check_for_errors) /* Wait for subprocess(es) to exit. */ if (g->recovery_proc /* RHBZ#998482 */ && data->pid > 0) { - if (waitpid (data->pid, &status, 0) == -1) { -...

As the start of work to add remote support, I'm taking a close look at the protocol layer in the library. These are some small cleanups. Rich.

As Eric Blake noted in: https://www.redhat.com/archives/libguestfs/2016-April/msg00154.html libguestfs doesn't correctly handle the case where waitpid receives a SIGCHLD signal and the main program has registered a non-restartable signal handler. In this case waitpid would return -EINTR and we would print an error, but actually we should retry this case. This adds two new internal functions,

...*/ + r = guestfs_max_disks (g); + if (r == -1) + return -1; + if (g->nr_drives > (size_t) r) { + error (g, _("too many drives have been added, the current backend only supports %d drives"), r); + return -1; + } + /* Start the clock ... */ gettimeofday (&g->launch_t, NULL); TRACE0 (launch_start); -- 2.9.3

v1 was here: https://www.redhat.com/archives/libguestfs/2017-April/msg00268.html v1 broke some tests because the guestfs_max_disks API isn't supported by some backends, specifically ?unix:?. This makes failure of guestfs_max_disks non-fatal. Rich.

...disks (g); + guestfs_pop_error_handler (g); + if (r >= 0 && g->nr_drives > (size_t) r) { + error (g, _("too many drives have been added, the current backend only supports %d drives"), r); + return -1; + } + /* Start the clock ... */ gettimeofday (&g->launch_t, NULL); TRACE0 (launch_start); -- 2.9.3

These three patches (for discussion only, NOT to be applied) implement a mutex system that lets the user limit the number of libguestfs instances that can be launched per host. There are two uses that I have identified for this: firstly so we can enable parallel-tests (the default in automake >= 1.13) without blowing up the host. Secondly oVirt has raised concerns about how to limit the

v1 was here: https://www.redhat.com/archives/libguestfs/2013-August/msg00005.html This now works, to some extent. The main problem now is that devices are named /dev/ubd[a-] which of course confuses everything. I'm thinking it may be easier to add a udev rule to rename them. Rich.

This is a User-Mode Linux backend for libguestfs. You can select it by doing: export LIBGUESTFS_BACKEND=uml export LIBGUESTFS_QEMU=/path/to/vmlinux Note we're reusing the 'qemu' variable in the handle for convenience. QEmu is not involved when using the UML backend. This almost works. UML itself crashes when the daemon tries to connect to the serial port. I suspect it's

This attempts to implement the idea proposed in https://www.redhat.com/archives/libguestfs/2010-April/msg00087.html The idea is that an externally managed QEMU (manual, or via libvirt) can boot the appliance kernel/initrd. libguestfs can then be just told of the UNIX domain socket associated with the guest daemon. An example based on guestfish. 1. Step one, find the appliance kernel/initrd

...char *msg; - int err; - struct timeval tv; - - va_start (args, fs); - err = vasprintf (&msg, fs, args); - va_end (args); - - if (err < 0) return; - - gettimeofday (&tv, NULL); - - debug (g, "[%05" PRIi64 "ms] %s", - guestfs_int_timeval_diff (&g->launch_t, &tv), msg); - - free (msg); -} - /* Compute Y - X and return the result in milliseconds. * Approximately the same as this code: * http://www.mpp.mpg.de/~huber/util/timevaldiff.c -- 2.7.4

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

...rogress messages it sends (see C<daemon/proto.c:notify_progress>). Not all calls generate diff --git a/src/proto.c b/src/proto.c index 549734b..6a0fbbf 100644 --- a/src/proto.c +++ b/src/proto.c @@ -193,8 +193,7 @@ child_cleanup (guestfs_h *g) g->recoverypid = 0; memset (&g->launch_t, 0, sizeof g->launch_t); g->state = CONFIG; - if (g->subprocess_quit_cb) - g->subprocess_quit_cb (g, g->subprocess_quit_cb_data); + guestfs___call_callbacks_void (g, GUESTFS_EVENT_SUBPROCESS_QUIT); } static int @@ -237,13 +236,8 @@ read_log_message_or_eof (guestfs_h *g, i...

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.

Output is configurable, it's the same format as virt-log has, since both uses same code. First patch moves get_journal_field around and renames it to journal_view and the next one reimplements it a bit and brings it to guestfish. Maros Zatko (2): cat: move get_journal_field to fish/journal.c fish: add journal-view command (RHBZ#988100) .gnulib | 2 +-

libguestfs has used double and triple underscores in identifiers. These aren't valid for global names in C++. (http://stackoverflow.com/a/228797) These large but completely mechanical patches change the illegal identifiers to legal ones. 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

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

Lots of changes since v2, too much to remember or summarize. Please ignore patch 11/11, it's just for my testing. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2016-March/thread.html#00157 Not running the 'hwclock' command reduces boot times considerably. However I'm not sure if it is safe. See the question I posted on qemu-devel: http://thread.gmane.org/gmane.comp.emulators.qemu/402194 At the moment, about 50% of the time is consumed by SeaBIOS. Of this, about ⅓rd is SGABIOS