similar to: [PATCH] lib: Increase default memory assigned to the appliance.

On Sat, Jun 11, 2016 at 08:51:56PM +0300, Pavel Butsykin wrote: > The appliance memory size of 500 MB is insufficient in certain scenarios. In > partiuclar, semodule (which may be called by a guest tools uninstaller) often > triggers OOM (see https://bugzilla.redhat.com/426775) > > Increase it to 768 MB. > > Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com> >

With recent Linux kernels, adding and partitioning 255 disks causes the appliance to run out of memory. This causes a test failure in tests/disks/test-255-disks.sh. This change gives the appliance enough memory to complete the test. --- lib/guestfs-internal.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index

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

Argon2 is the default LUKS Password-Based Key Derivation Function (PBKDF) for some new guests such as RHEL 8.2 and Fedora. It is designed to be "memory hard", meaning that by design it requires large amounts of memory, making it expensive to brute-force. Unfortunately the default for guests which had more than a few GB of RAM at install time is to require about 1 GB of RAM to decrypt

https://bugs.launchpad.net/qemu/+bug/1740364 --- lib/guestfs-internal.h | 3 +++ lib/handle.c | 2 ++ lib/info.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index adeb9478a..c66c55e70 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -510,6 +510,9 @@ struct

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.

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

On Wednesday, 16 May 2018 14:43:09 CEST Richard W.M. Jones wrote: > With recent Linux kernels, adding and partitioning 255 disks causes > the appliance to run out of memory. This causes a test failure in > tests/disks/test-255-disks.sh. This change gives the appliance enough > memory to complete the test. TBH raising the amount of memory only for those tests is the solution IMHO,

Thanks: Cole Robinson, Dan Horak, Thomas Huth. --- lib/launch-libvirt.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c index f66c8e0ef..4adb2cfb3 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -1359,6 +1359,7 @@ construct_libvirt_xml_devices (guestfs_h *g, return -1; } +#ifndef __s390x__ /*

I wonder why not to set required amount of memory using guestfs_set_memsize or setting LIBGUESTFS_MEMSIZE environment variable just for this test? -- +380979184774 Mykola Ivanets ср, 23 трав. 2018 о 11:28 Pino Toscano <ptoscano@redhat.com> пише: > On Wednesday, 16 May 2018 14:43:09 CEST Richard W.M. Jones wrote: > > With recent Linux kernels, adding and partitioning 255

Currently the tests fail on x86 with recent kernels: FAIL: test-255-disks.sh This confused me for a while because our other test program (utils/max-disks/max-disks.pl) reports that it should be possible to add 255 disks. Well it turns out that the default amount of appliance memory is sufficient if you're just adding disks, but if you try to add _and_ partition those disks there's

NB: This requires a qemu patch by Eduardo which is currently awaiting review: https://www.mail-archive.com/qemu-devel@nongnu.org/msg422959.html So not to be applied yet unless that qemu change goes upstream. Rich.

Use %d to parse them as int (since the variables for them as int) instead of %u, even if they both need to be at least > 0. --smp was already checked to be >= 1 while --memsize not, so check that the specified memory size is not < 128 (which is semi-arbitrary, but enough as a minimum threshold). --- rescue/rescue.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)

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

Why does the toplevel Makefile process appliance/, and creates supermin.d during make install, whith configure --disable-appliance? I have to double check what actually happens, it seems it causes startup failures if the resulting binary packages are started on a host that happens to have supermin installed. Olaf

On Wednesday, 16 May 2018 13:51:20 CEST Richard W.M. Jones wrote: > --- > tests/disks/test-add-disks.c | 9 +++++++++ > utils/max-disks/max-disks.pl | 1 + > 2 files changed, 10 insertions(+) > > diff --git a/tests/disks/test-add-disks.c b/tests/disks/test-add-disks.c > index a7365d1d1..f3eb87bb4 100644 > --- a/tests/disks/test-add-disks.c > +++

https://bugzilla.redhat.com/show_bug.cgi?id=769680

Couple of notes: (1) You may need to 'make clean' after applying this patch. There is some missing dep so it seems the appliance isn't fully rebuilt. (2) [Comment mainly directed to Matt] This is not a candidate to be automatically added to the stable 1.2 branch. It's far too large of a change for a stable release. Since this change may be required for V2V, please clone

[First attempt to send this using git send-email didn't work because of SMTP routing problems] Hilko, This is my experimental patch to remove update-guestfs-appliance from Debian. With this patch, libguestfs builds with a supermin [version 5] appliance in /usr/lib/guestfs/supermin.d: $ ll -h /usr/lib/guestfs/supermin.d/ total 884K -rw-r--r-- 1 root root 94K Mar 15 12:18 base.tar.gz