On Tue, Feb 07, 2023 at 08:56:06AM +0000, Daniel P. Berrangé wrote: > 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.
Discussion on the orignal patch: https://listman.redhat.com/archives/libguestfs/2022-April/thread.html#28711 Maybe we discussed migratability on IRC or on some previous thread, but all I can find there is the same commit message. (OTOH I did review the patch and didn't query it, so ...) I just posted a patch to change this from host-passthrough to host-model, because I think we don't need to hinder live migration if there's an easy way to do that. > > 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. Is there any easy way to query libvirt to find out what is the best x86-64-vX compatible CPU available? Sometimes we are connected to libvirt on the output side. > > (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/a3e45b3ea5b45e682cb4b7ad3a5646586c6c7886 > > > > 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. OK. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
