Hi Guido,
And thanks for that quick feedback. From what you wrote and the post you
linked Yesterday I understand that's not a bug, or at least not a Debian
bug, but something which requires (as of now) more configuration than a
simple "setvcpus" while the guest is running.
I gave a try to your suggestion (that is: reboot the guest) and the
situation didn't change : vcpuinfo or vcpucount still gives me back 1
vcpu, while the guest sees (and uses) 2 vcpus.
I think it's related to the fact that the definition file wasn't
(automatically) changed, even with that "setvcpus <domain> 1" command.
It's still
"<vcpu placement='static'>2</vcpu>"
and there is no "current" flag as stated in the post you linked (<vcpu
placement='static' current='1'>2</vcpu>)
Unless I'm mistaken, that means that the only way to modify the number
of cpus a guest can run on is to shutdown the guest, modify the
definition file and switch it on back.
Regards,
Loïc
Le 19/03/2014 20:17, Guido Günther a écrit :
Hi,
While on the guest side a cat /proc/cpuinfo still gives back two cpu available.
This needs support from qemu and (at least last time I checked) a
running guest agent. This isn't available in wheezy so you should see
the updated CPUs after reboot only. See. e.g.:
http://lost-and-found-narihiro.blogspot.ch/2013/10/fedora-19-kvm-cpu-hotplug-with-qemu.html
So libvirt tries to cope with it.
Cheers,
-- Guido
