Re: [Libguestfs] [PATCH v2v] convert: linux: Require host cpu for all RHEL-alike >= 9

On Mon, Feb 06, 2023 at 12:49:41PM +0000, Richard W.M. Jones wrote: > (2) If the guest is RHEL family >= 9, use -cpu host / host-passthrough > > (3) Otherwise don't specify any -cpu or <cpu> section > > The third option seems to cause qemu / libvirt to use qemu64. However > it has the advantage that the guest is migratable afterwards. I vaguely recall in previous discussion that we decided not to care if the guest is migratable or not, on the basis that wasn't really domain knowledge of v2v nor an user request. Thus the use of 'host-passthrough' rather than 'host-model' to give a "perfect" match for the host, rather than approximation.

> There may be a case for changing this so: > > (a) Rule (2) is changed so we use host-model (for the libvirt target). All hinges on whether users expect the output of v2v to be migratable or not. > (b) Rule (3) is changed so we always specify a minimum CPU, eg. > for x86-64 guests, choose x86-64-v2 (is that an actual CPU model??) In the case of x86-64-v2 it is the QEMU Nehalem model is a perfect match, and is capable of running on both Intel and AMD hosts. This is mostly luck though. For x86-64-v3 / -v4 ABIs there is no viable model that will run on both AMD and Intel. So once there's a guest OS that mandates -v3, we'll be back to wanting host-model/passthrough.

> (a) seems like a no-brainer. Not sure why we chose host-passthrough > instead of host-model? The explanation in the commit message is not > very convincing: > https://github.com/libguestfs/virt-v2v/commit/a3e45b3ea5b45e682cb4b7ad3a5... > > I think (b) is fraught because it is my understanding that there is no > good choice for a minimum CPU since we don't know anything about the > target hardware (eg. if it's Intel or AMD). And on !x86-64 we really > have no idea at all what's a good choice. Yeah, I'd recommend against (b). IMHO mgmt apps / provisioning tools should only ever choose host-model or host-passthrough for KVM. Use of an explicit named CPU model should be something left to admins to decide based on their global knowledge of what machines they need to migrate across. Ignoring named models also nicely avoids the problem of needing knowledge across all arches. If you care about TCG, you could use 'maximum' instead of 'host-passthrough'. They are identical in the case of KVM, and for TCG 'maximum' just gives you all possible features.