similar to: [PATCH] lib: Increase default memsize to 1280 (RHBZ#1837765).

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

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

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

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

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

Alternate way to fix test-255-disks.sh running out of memory. See previous discussion here: https://www.redhat.com/archives/libguestfs/2018-May/msg00082.html Rich.

On Wed, Feb 01, 2017 at 03:53:52PM +0100, Pino Toscano wrote: > On Wednesday, 1 February 2017 13:40:17 CET Richard W.M. Jones wrote: > > In commit 08f82f2e3d6975b72340dd59f438862e152a15ef we increased the > > memory size to 800MB (on x86) so that the semodule command would work. > > > > However it has been discovered that another SELinux command takes > > large

+1 LGTM. Thanks Richard. On Fri, Sep 21, 2018 at 12:53 PM Richard W.M. Jones <rjones@redhat.com> wrote: > 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

As you know, HVM save/restore broke recently because restored config miss guest memsize that used by xc_hvm_restore to locate some pfn. After discussion, we decided to remove the pfn deduction logic from restore side by adding a general memory layout. I have a patch for it. But then qemu broke, because it also require the memsize to locate the share page. We can''t use the previous

I?ve got a 512M machine and a 330M ( uncompressed ) initrd image. How can I mount the ramdisk? Normal booting seems to want to copy the entire initrd image into a Ramdisk, thus requiring 2X the memory. So what happens is the kernel boots correctly and I get, RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 330000 blocks [ 1 disk ] into ram disk And then I never see the light of day after

I?ve got a 512M machine and a 330M ( uncompressed ) initrd image. How can I mount the ramdisk? Normal booting seems to want to copy the entire initrd image into a Ramdisk, thus requiring 2X the memory. So what happens is the kernel boots correctly and I get, RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 330000 blocks [ 1 disk ] into ram disk And then I never see the light of day after

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

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,

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

In commit 08f82f2e3d6975b72340dd59f438862e152a15ef we increased the memory size to 800MB (on x86) so that the semodule command would work. However it has been discovered that another SELinux command takes large amounts of RAM (setfiles during the SELinux relabel step). Therefore increase the memory size again, this time to 2000MB. --- v2v/v2v.ml | 2 +- v2v/virt-v2v.pod | 2 +- 2 files

Hi everyone, lately I've been getting familiar with library and working on slight re-layering of the library. It's about having locking layer in public API and tracing one layer below that (let's call it __t_ layer. I'm not very good at making up names, so this is temporary:) ). Then making sure that all generated public stuff call __t_ layer and all other internal stuff

Is there any information on adding support for Argon2? I have been working on my new mailserver and this came up in moving from the default MD5 hash to more 'modern' hashes like SHA256 and SHA512.? Then I was pointed to the work behind Argon2, and I see that it is moving through the IRTF cfrg workgroup: draft-irtf-cfrg-argon2-04.txt It is a 'purpose built' hash for passwords,

I am using a FreeBSD 11-2 amd/64 system with dovecot version 2.3.4 installed. I was playing around with different encryption schemes. doveadm pw -l SHA1 SSHA512 BLF-CRYPT PLAIN HMAC-MD5 OTP SHA512 SHA RPA DES-CRYPT CRYPT SSHA MD5-CRYPT SKEY PLAIN-MD4 PLAIN-MD5 SCRAM-SHA-1 LANMAN SHA512-CRYPT CLEAR CLEARTEXT SSHA256 NTLM MD5 PBKDF2 SHA256 CRAM-MD5 PLAIN-TRUNC SHA256-CRYPT SMD5 DIGEST-MD5

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 17 February 2019 at 10:38 Odhiambo Washington via dovecot < <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a>> wrote:

On 2/13/19 8:30 AM, Aki Tuomi wrote: > On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: >> >> On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: >>> >>> Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz >>> <rgm at htt-consult.com>: >>> >>>> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote: