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

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.

So ... my question now is, should we simply remove the vendor and
model fields completely?

I'll ACK the v2 patch anyway (in a minute).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

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