CCing Cole, as he had to deal with libvirt and "host-cpu" before, and may have some comments about the bugs he has found. On Fri, May 02, 2014 at 01:07:05PM +0100, Richard W.M. Jones wrote: I see no reason to _not_ choose Opteron_Gx, if you know the host CPU is always going to be an Opteron_Gx. If the user simply plans to convert an existing physical machine to a single-VM machine and has no plans to ever migrate the VM, it makes sense to use "-cpu host" (but beware: this may uncover a few QEMU bugs). if the user plans to migrate the VM to a _similar_ host later, it makes sense to use an existing CPU model name that matches the host CPU (see "host-cpu-model" below). If the user plans to migrate the VM to a very different host later it makes sense to be more conservative and simply use the default CPU model. In other words: I don't know what's a good default because I don't know your use case very well. The best possible CPU is "-cpu host" (host-passthrough in libvirt), but that doesn't allow migration. This may uncover QEMU bugs (but it is much better today than it was 1 or 2 years ago). The best possible CPU which allows migration is the one you get when explicitly asking libvirt to expand host-model (including baseline + flags). This is likely to uncover QEMU and libvirt bugs. A safer option is to use only the base CPU model (not the additional flags) provided by libvirt when asking about the host CPU model (I believe this is called "host-cpu-model" on virt-manager code). I wouldn't recommend this unless: 1) you know the VM will be kept running in the same host or on a similar host; 2) you pin the VCPUs/threads to corresponding host CPUs/threads. This may also uncover QEMU bugs, so I wouldn't do this by default unless the user explicitly asks for it. In the future you may want to support multi-node NUMA VMs. This is similar to the multi-core/multi-thread case: it makes sense if you know the VM is going to run on a host with similar topology, and if you manually pin the guest nodes to the host nodes (something which is not possible yet, but should be possible in the near future). -- Eduardo

On Fri, May 02, 2014 at 08:10:47PM +0100, Richard W.M. Jones wrote: That's interesting. So you have many reasons to be conservative by default, unless you (or the user) have additional information about the target machine/cluster where the VM is going to run. Is the p2v tool going to accept options similar to the virt-install options? Except for additional conversion steps, the process look very similar to the creation of a new VM: only the user (or management software using the tool/library) has enough information to decide how the new VM should really look like. It should, and if you are not getting it, there are even more reasons to worry about the safety of using "baseline+features" instead of just "baseline" because it means something unexpected happened. It is not a bug, strictly speaking, but something we want to avoid. If you are getting "-cpu NotSoNiceCPU,+NiceFeature1,+NiceFeature2" as result from libvirt instead of "-cpu NiceCPU" (which would already contain NiceFeature1, NiceFeature2), please bug us (libvirt and QEMU developers) so we can address it. On both cases above (cores/sockets and NUMA), it doesn't make much sense to try to copy the original topology unless you want to fine-tune VCPU and memory pinning to maximize performance. So considering you don't know much about the new host machine, I don't see a reason to try to copy the original machine topology by default. -- Eduardo