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