On Fri, Sep 18, 2020 at 02:03:00PM +0200, Pino Toscano wrote:
On Friday, 18 September 2020 11:44:04 CEST Richard W.M. Jones wrote:
> let g = open_guestfs ~identifier:"v2v" () in
> g#set_memsize (g#get_memsize () * 14 / 5);
> + (* Setting the number of vCPUs allows parallel mkinitrd. *)
> + g#set_smp (Sysconf.nr_processors_online ());
IMHO this is not a good idea, for few reasons:
a) it unconditionally uses all the available CPUs with no way to change
it to any other value
My second suggestion would be to use:
+ g#set_smp (min 8 (Sysconf.nr_processors_online ()));
(limit to be discussed, but here I arbitrarily chose 8). I agree that
it's not a good idea to use all CPUs. However:
b) virt-v2v is run also on systems that are not specifically
dedicated
as conversion servers, for example the oVirt hosts (that run the oVirt
VMs); in this context, suddently using more CPUs than requested may
saturate the system resources
It's fairly unlikely this would happen. All the libguestfs steps are
still serialized. Only a few steps would use all CPUs, including
dracut/mkinitrd, and possibly some RPM commands.
IMHO the right approach is to add a --smp N option like available in
other libguestfs tools; this way, the user can decide how many
resources virt-v2v can use.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v