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

[Daniel P. Berrangé]

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 :|