[Pkg-libvirt-maintainers] Bug#742076: Bug#742076: libvirt-bin: setvcpus command fails to shrink the numbers of vcpu

[Sdkfz262]

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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20140320/72d45b81/attachment.html>