similar to: [PATCH 1/2] p2v: Free config struct before exit.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1792141 Let the user pass "-oo" options from the kernel cmdline and from the GUI to virt-v2v. This is primarily useful with the OpenStack output mode, so reenable that mode. Cc: Alban Lecorps <alban.lecorps at ubisoft.com> Laszlo Alban Lecorps (1): Introduce "p2v.output.misc" for passing "-oo" options

From: Alban Lecorps <alban.lecorps at ubisoft.com> The "-oo" option will be useful primarily for the openstack output mode (currently disabled, from commit b74c126629e3, "Ignore 'openstack' driver", 2020-03-16). Use a ConfigStringList knob for "-oo", and for each OPTION=VALUE element in that list, create a separate "-oo OPTION=VALUE" option.

These are a prelude to fixing https://bugzilla.redhat.com/show_bug.cgi?id=1590220 A lot of the virt-p2v configuration code was duplicated manually. These changes make sure that most of it is generated. Rich.

As preliminary steps in splitting virt-p2v to an own repository, start making p2v more independent within libguestfs. This is accomplished by the following changes: - generate the p2v kernel config sources & docs at build time using a Perl script, rather than the generator (so no need for OCaml when building from git, and no generated sources in dist tarballs) - create two local test

A mixed bag, but all the patches make sense together! Patch 1: Fix a bug that Tingting found: https://bugzilla.redhat.com/show_bug.cgi?id=1256222 Patch 2: Revert a patch that makes no sense now that we've added virt-v2v into base RHEL. This is just included because it's a cleanup needed before applying patch 3. Patch 3: Add the ability to use SSH identities (private keys) for virt-p2v

Fixes https://bugzilla.redhat.com/1256222

I worked out why valgrind wasn't being applied to nbdkit when run by many of the tests (patches 1-2). Unfortunately I'm not able to make it actually fail tests when valgrind fails. Although the situation is marginally improved in that you can now manually examine the *.log files and find valgrind failures that way. Also adds valgrinding of the Python plugin (patch 3). Along the way I

When we are valgrinding we don't really care about the child processes, which might be qemu, libvirtd, etc. So disable tracing into children (at least, as far as is possible with valgrind, which is not entirely disabling it, but suppressing it). --- m4/guestfs_progs.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/guestfs_progs.m4 b/m4/guestfs_progs.m4 index

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

On 12/2/18 10:39 AM, Richard W.M. Jones wrote: > By default valgrind suppresses many leaks. I'm not even sure exactly > how it decides which ones to suppress, but certainly global variables > pointing to malloc’d data are suppressed, which is not useful > behaviour. Here's my understanding of why that is the default - if you assign malloc()d storage into a global, then that

On 12/3/18 1:01 PM, Richard W.M. Jones wrote: > >>> passthru ("--error-exitcode=119"); >>> - passthru_format ("--suppressions=%s/valgrind-suppressions", srcdir); >>> + passthru_format ("--suppressions=%s/valgrind/suppressions", builddir); >> >> Is this still right under VPATH? > > I believe so ...? Note

Don't get the CPU information from libvirt, because including libvirt and all dependencies in the virt-p2v ISO bloats everything. Instead get most of the information we need from the util-linux program 'lscpu'. Unfortunately the CPU model cannot be retrieved. Example output: $ ./run virt-p2v --cmdline="p2v.dump_config_and_exit" [...] cpu vendor . . . Intel cpu

Fixes for various issues found while implementing my nbd forwarder plugin. I'm okay if you choose to take some but not others; the most important one is patch 3 which fixes a protocol violation that makes it impossible for a client to try and recover from EIO failures over a partially-flaky source block device. Eric Blake (3): maint: Add emacs hint file maint: Add NBDKIT_GDB support to

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.

David Blaikie <dblaikie at gmail.com> writes: > Selfhost clang. Whenever we get a warning from Clang we either fix > Clang or fix the build quite quickly. Not possible, > If you want to fix the build such that LLVM can be built -Werror clean > with GCC the right solution is going to be to turn off -Wuninitialized > when the LLVM build system detects that it is using GCC

David Blaikie <dblaikie at gmail.com> writes: > The other point Chandler was making, though, was that this sort of fix > means that other tools (Valgrind/MemSan) won't catch a broader class > of errors because we will have silenced them too. Does buildbot do a valgrind build with the same frequency as any other build? If so, then either we should fix the warnings or we should

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

Instead of generating the p2v kernel config using the OCaml generator, create a Perl script to do this job, mostly at build time. This is done to rely less on the generator for p2v, and because the generation of these sources is quick enough that it can be done at build time (instead of shipping the generated sources in dist tarballs). The generate-p2v-config.pl mimics what

v3: - Don't remove the LVM transform.