[...] > The choice of Nehalem, Opteron, etc as CPU models is already supported > in QEMU and influences guest CPU performance. You're not explaining why > we need to introduce multiple CPU <cpu driver='qemu64-x86_64-cpu'> values. > It makes no sense to have two different CPU models listed for the same > guest like this. > Hi Daniel, Maybe I misunderstood your meaning. Next I will let you know what we think in detail. libvirt already implements Vcpu hotplug for qemu driver by qemu command 'cpu-add', but Vcpu hot-unplug has not been implemented. qemu prefers to implement Vcpu hotplug by command 'device_add' instead of 'cpu-add', implement Vcpu hotplug by command 'device_del' in future. So, according to the above, our team has the following two methods to implement Vcpu hotplug/un-plug in libvirt. 1) improve the existing API, and use the old command 'setVcpus'. This method will invoke qemu's command 'device_add' instead of 'cpu-add'. This method has three problems: a) can not specific the cpu' model. This will change qemu's design for cpu hotplug. b) can not keep consistent with other devices' hotplug in libvirt. c) influence cpu's hot-unplug. If device_add a cpu without id (i.e. device alias name in libvirt), cpu hot-unplug can not work. 2) Add a new API to support cpu hot-plug/unplug, and leave the the existing API as a legacy. This method will realize the feature by libvirt command 'attach-device', and will allow user to specify the cpu model. And in the future, we want to make struct virCPUDefPtr as a member of the new defined struct for hotplugged cpu device, so that We can allow user to set more details for cpu device, not only cpu model. This method has two advantages. a) keep consistent with other devices' hotplug in libvirt. b) can assign device alias name. This is helpful for cpu hot-unplug. The above is our opinion. May you give us some suggestions? Regards, Zhu -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list