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

[Richard W.M. Jones]

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