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/11505e4b84ce8d7eda4e2a275fdcec...
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