On Fri, Jul 22, 2022 at 12:53:00PM +0100, Daniel P. Berrangé wrote: > On Fri, Jul 22, 2022 at 01:49:21PM +0200, Laszlo Ersek wrote: > > On 07/22/22 11:50, Richard W.M. Jones wrote: > > > 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. > > > > I think producing host-passthrough indiscriminately on output (which we > > already do in the particular case only when the source does not specify > > a model and we know an OS does not run on qemu64) would be best. I don't > > think it would be a very difficult patch or patch set, but I dread the > > testing of it. :/ > > > > Let me go ahead and commit v2; and let's remember this discussion for > > the next time a CPU model related problem pops up. If switching to > > host-passthrough solves that problem then, we should implement it then. > > (And then ask QE to test it as comprehensively as they can...) > > Remember, 'host-passthrough' is only possible with KVM, not TCG, > 'host-model' works with both. If you have newish libvirt + QEMU > you can use 'maximum' which is equiv to 'host-pasthrough' on > KVM, or "all implemented features" on TCG.
host-model is the only one which allows migration? This choice of CPU model only really matters for local conversions (-o libvirt, -o local, -o qemu). For conversions to target hypervisors we can probably let them choose. 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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
