> A question arose in today's kvm meeting concerning any > impact to libvirt from this change. I've discussed it > with Cole and it seems to be a non-issue. But just to > err on the side of caution, here's a summary: > > The current cpu model definition of "qemu64" upstream > is problematic from kvm's perspective such that we need > to modify it slightly (BZ justifications listed below). > Doing so we've left the qemu64 definition as-is, but > added "cpu64-rhel6" and "cpu64-rhel5" models which > are now selected by default via "-M <machine>", for > "RHEL 6.0.0 PC" and "RHEL 5.x.y PC" respectively.
I was following the whole thread and I would have stepped in in case libvirt was affected by the change. Still, thanks for keeping libvirt on your mind. > So the only issue would be libvirt invoking qemu with > neither a "-cpu" nor "-M" argument (which defaults to > qemu64) or explicitly requesting "-cpu qemu64". > > >From my discussion with Cole it appears the use cases > where this may happen fall outside of routine/expected > usage and would need to be explicitly requested by the > user. However I wanted to call this out here in the > event we're overlooking something. Yeah, libvirt basically never runs qemu without -M option and the only way to get -cpu qemu64 is to explicitly ask for it in guest XML. There is a scenario when libvirt creates -cpu option for qemu even though no cpu requirements were specified in guest XML but it only happens for 32b guests on 64b hosts and qemu32 CPU model is used in that case, which should be OK since the problem is only about qemu64. And IIUC we don't want users to be able to specify the new cpu64-rhel[56] models directly in guest XML so there's nothing to be done on libvirt side. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
