Libguestfs - Feb 2017 - Re: [PATCH] v2v: Further increase memory allocated to the appliance (RHBZ#1418283).

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 changed, 2 insertions(+), 2 deletions(-)

diff --git a/v2v/v2v.ml b/v2v/v2v.ml
index e85e96f..a711121 100644
--- a/v2v/v2v.ml
+++ b/v2v/v2v.ml
@@ -75,7 +75,7 @@ let rec main ()    );
 
   let g = open_guestfs ~identifier:"v2v" () in
-  g#set_memsize (g#get_memsize () * 8 / 5);
+  g#set_memsize (g#get_memsize () * 20 / 5);
   (* The network is only used by the unconfigure_vmware () function. *)
   g#set_network true;
   (match conversion_mode with
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index 4614888..88bfd7f 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -1634,7 +1634,7 @@ alleviate this.
 
 Virt-v2v is not especially compute or RAM intensive.  If you are
 running many parallel conversions, then you may consider allocating
-one CPU core and between 512 MB and 1 GB of RAM per running instance.
+one CPU core and 2 GB of RAM per running instance.
 
 Virt-v2v can be run in a virtual machine.
 
-- 
2.10.2

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 amounts of RAM (setfiles during the SELinux relabel step).
> Therefore increase the memory size again, this time to 2000MB.
> ---
LGTM.

Should v2v get a -m parameter like the other tools?
> diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
> index 4614888..88bfd7f 100644
> --- a/v2v/virt-v2v.pod
> +++ b/v2v/virt-v2v.pod
> @@ -1634,7 +1634,7 @@ alleviate this.
>  
>  Virt-v2v is not especially compute or RAM intensive.  If you are
>  running many parallel conversions, then you may consider allocating
> -one CPU core and between 512 MB and 1 GB of RAM per running instance.
> +one CPU core and 2 GB of RAM per running instance.
I guess pointing to LIBGUESTFS_MEMSIZE here could make it more
actionable on issues.

Thanks,
-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20170201/240729eb/attachment.sig>

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 amounts of RAM (setfiles during the SELinux relabel step).
> > Therefore increase the memory size again, this time to 2000MB.
> > ---
> 
> LGTM.
> 
> Should v2v get a -m parameter like the other tools?
Because with v2v we want to automate the transfer of hundreds or
thousands of guest, we should avoid per-guest tweaks, which is
essentially what the -m flag would be.

However there is an issue with any other tools doing an
selinux_relabel (API).  Probably on some guests they will also run out
of memory.  We could increase the appliance size for everyone, but I
think it's better to fix the memory leak or whatever in setfiles.
> > diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
> > index 4614888..88bfd7f 100644
> > --- a/v2v/virt-v2v.pod
> > +++ b/v2v/virt-v2v.pod
> > @@ -1634,7 +1634,7 @@ alleviate this.
> >  
> >  Virt-v2v is not especially compute or RAM intensive.  If you are
> >  running many parallel conversions, then you may consider allocating
> > -one CPU core and between 512 MB and 1 GB of RAM per running instance.
> > +one CPU core and 2 GB of RAM per running instance.
> 
> I guess pointing to LIBGUESTFS_MEMSIZE here could make it more
> actionable on issues.
OK, I will tweak this documentation.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/