Libguestfs - Jul 2022 - [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute

On Fri, Jul 22, 2022 at 10:34:44AM +0100, Richard W.M. Jones
wrote:
> Sorry for the delayed response to this.  I see you've posted an
> updated patch, so this is just a bit of FYI.
> 
> I originally added CPU modelling in commit 11505e4b84 (March 2017):
> 
>
https://github.com/libguestfs/virt-v2v/commit/11505e4b84ce8d7eda4e2a275fdcecc5f2a3288d
> 
> What we were actually trying to achieve here was to preserve the CPU
> topology.  I believe the request came from Bill Helgerson who was
> working on v2v in the proto-IMS product, and was working a lot with
> customers.
> 
> You can see in the code before the patch is applied we only modelled
> the number of vCPUs.  Afterwards we have:
> 
>  * number of vCPUs
>  * vendor (eg. AMD)
>  * model (eg. EPYC)
>  * sockets
>  * cores per socket
>  * threads per core
> 
> I think here only the first 1 and last 3 (#vCPUS, topology) are really
> important.  I believe I added the vendor and model just because they
> were there, without necessarily thinking too deeply about the
> implications.
> 
> As you covered in your email, what is the real meaning of converting a
> source guest using eg AMD/EPYC with virt-v2v to some target?  Does it
> mean that the target must be able to emulate all EPYC feature (likely
> impossible if the target is Intel)?  I would say it's not that
> important.  This isn't live migration, and almost all guests can be
> booted interchangably on different x86_64 hardware.
> 
> Is topology important?  I would say yes, or at least it's much more
> important than vendor/model.  Workloads may expect not just a number
> of vCPUs, but a particular layout, especially the larger and more
> complex ones.
In terms of topology, if you have NOT set pCPU:vCPU 1:1 pinning,
then NEVER set threads > 1. There's a choice of sockets vs cores
for non-pinned scenario, and generally I'd recommends 'cores'
always because high core counts are common in real world, and
'sockets' mostly maxes out at 2/4 in real world (ignoring wierd
high end hardware), also some OS restrict you based on sockets,
but not cores. So IMHO the only compelling reason to use
sockets > 1 is you want to have virtual NUMA topology, but
even that's dubious unless pinning.

If you have set pCPU:vCPU 1:1 pinning, then set topology to
try to match what you've pinned to.
> So ... my question now is, should we simply remove the vendor and
> model fields completely?
Removing 'model' is not a good idea, as you'll get the default
CPU model.

If you don't have to pick a particular CPU, then IMHO either
use host-model or host-passthrough depending on whether you
think live migration is important or not.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Fri, Jul 22, 2022 at 10:42:48AM +0100, Daniel P. Berrang?
wrote:
> On Fri, Jul 22, 2022 at 10:34:44AM +0100, Richard W.M. Jones wrote:
> > Sorry for the delayed response to this.  I see you've posted an
> > updated patch, so this is just a bit of FYI.
> > 
> > I originally added CPU modelling in commit 11505e4b84 (March 2017):
> > 
> >
https://github.com/libguestfs/virt-v2v/commit/11505e4b84ce8d7eda4e2a275fdcecc5f2a3288d
> > 
> > What we were actually trying to achieve here was to preserve the CPU
> > topology.  I believe the request came from Bill Helgerson who was
> > working on v2v in the proto-IMS product, and was working a lot with
> > customers.
> > 
> > You can see in the code before the patch is applied we only modelled
> > the number of vCPUs.  Afterwards we have:
> > 
> >  * number of vCPUs
> >  * vendor (eg. AMD)
> >  * model (eg. EPYC)
> >  * sockets
> >  * cores per socket
> >  * threads per core
> > 
> > I think here only the first 1 and last 3 (#vCPUS, topology) are really
> > important.  I believe I added the vendor and model just because they
> > were there, without necessarily thinking too deeply about the
> > implications.
> > 
> > As you covered in your email, what is the real meaning of converting a
> > source guest using eg AMD/EPYC with virt-v2v to some target?  Does it
> > mean that the target must be able to emulate all EPYC feature (likely
> > impossible if the target is Intel)?  I would say it's not that
> > important.  This isn't live migration, and almost all guests can
be
> > booted interchangably on different x86_64 hardware.
> > 
> > Is topology important?  I would say yes, or at least it's much
more
> > important than vendor/model.  Workloads may expect not just a number
> > of vCPUs, but a particular layout, especially the larger and more
> > complex ones.
> 
> In terms of topology, if you have NOT set pCPU:vCPU 1:1 pinning,
> then NEVER set threads > 1. There's a choice of sockets vs cores
> for non-pinned scenario, and generally I'd recommends 'cores'
> always because high core counts are common in real world, and
> 'sockets' mostly maxes out at 2/4 in real world (ignoring wierd
> high end hardware), also some OS restrict you based on sockets,
> but not cores. So IMHO the only compelling reason to use
> sockets > 1 is you want to have virtual NUMA topology, but
> even that's dubious unless pinning.
> 
> If you have set pCPU:vCPU 1:1 pinning, then set topology to
> try to match what you've pinned to.
> 
> > So ... my question now is, should we simply remove the vendor and
> > model fields completely?
> 
> Removing 'model' is not a good idea, as you'll get the default
> CPU model.
> 
> If you don't have to pick a particular CPU, then IMHO either
> use host-model or host-passthrough depending on whether you
> think live migration is important or not.
I mean remove them from virt-v2v's internal source model [confusing
terminology here - modelling the source != CPU model].  On targets
we'd choose something like cpu=host-model to get the best possible
migratable CPU.

The point is we're not copying the Intel / Nehalem, AMD / EPYC etc of
the guest from the source to the destination hypervisor.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit