Re: [Libguestfs] [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/11505e4b84ce8d7eda4e2a275fd... > > 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.