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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
