libvirt users - Feb 2020 - Re: can hotplug vcpus to running Windows 10 guest, but not unplug

----- On Feb 14, 2020, at 4:13 PM, Peter Krempa pkrempa@redhat.com wrote:
> 
> Sounds like qemu doesn't support unplug of vcpus. Which version of qemu
> do you use?
ha-idg-2:~ # rpm -qa|grep qemu
qemu-seabios-1.11.0-5.18.1.noarch
qemu-ovmf-x86_64-2017+git1510945757.b2662641d5-3.16.1.noarch
qemu-block-curl-2.11.2-5.18.1.x86_64
qemu-sgabios-8-5.18.1.noarch
qemu-x86-2.11.2-5.18.1.x86_64
libvirt-daemon-qemu-4.0.0-8.15.2.x86_64
qemu-ipxe-1.0.0+-5.18.1.noarch
qemu-tools-2.11.2-5.18.1.x86_64
qemu-vgabios-1.11.0-5.18.1.noarch
qemu-block-ssh-2.11.2-5.18.1.x86_64
qemu-kvm-2.11.2-5.18.1.x86_64
qemu-2.11.2-5.18.1.x86_64
libvirt-daemon-driver-qemu-4.0.0-8.15.2.x86_64
qemu-block-rbd-2.11.2-5.18.1.x86_64

I found a table on
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/virtual_machine_management_guide/cpu_hot_plug
saying that hotplugging is possible but no hotunplugging.
But i don't know how recent this information is and if RedHat uses
libvirt/qemu.

Bernd
Helmholtz Zentrum München

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir.in Prof. Dr. Veronika von Messling
Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Kerstin Guenther
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

On Fri, Feb 14, 2020 at 4:54 PM Lentes, Bernd <
bernd.lentes@helmholtz-muenchen.de> wrote:
>
> qemu-kvm-2.11.2-5.18.1.x86_64
>
> [...]
> I found a table on
>
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/virtual_machine_management_guide/cpu_hot_plug
> saying that hotplugging is possible but no hotunplugging.
> But i don't know how recent this information is and if RedHat uses
> libvirt/qemu.
>
>
RHV uses a special version of qemu-kvm named qemu-kvm-rhev.
oVirt, the upstream product of RHV, uses a rebuilt package named
qemu-kvm-ev.
Eg in oVirt 4.3.8, that is the latest stable release available right now
and should apply to your doc link limitations
is qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64
What is the OS of your hypervisor?
In case of CentOS 7 and not a production one, you could enable the repo
from CentOS-SIG-Virtualization like this:
https://wiki.centos.org/SpecialInterestGroup/Virtualization

A repo entry is this one below:

[ovirt-4.3-centos-qemu-ev]
name=CentOS-7 - QEMU EV
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/kvm-common/
gpgcheck=1
enabled=1
gpgkey=https://www.centos.org/keys/RPM-GPG-KEY-CentOS-SIG-Virtualization

Then deinstall qemu-kvm and install qemu-kvm-ev.
I don't remember if yum would detect qemu-kvm as an "obsolete"
version of
qemu-kvm-ev, probably yes and in this case you would only need to run
yum install qemu-kvm-ev
and it will replace the old.
Browse the repo packages in case, because it would bring in for example
also another version of seabios (I don't see libvirt packages in between).
But anyway for your special case also with qemu-kvm-ev it seems no Windows
OS is supported for hot unplug.
HIH,
Gianluca

On 2/14/20 11:17 AM, Gianluca Cecchi wrote:
> On Fri, Feb 14, 2020 at 4:54 PM Lentes, Bernd 
> <bernd.lentes@helmholtz-muenchen.de 
> <mailto:bernd.lentes@helmholtz-muenchen.de>> wrote:
> 
> 
>     qemu-kvm-2.11.2-5.18.1.x86_64
> 
> [...]
> 
>     I found a table on
>    
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/virtual_machine_management_guide/cpu_hot_plug
>     saying that hotplugging is possible but no hotunplugging.
>     But i don't know how recent this information is and if RedHat uses
>     libvirt/qemu.
> 
> RHV uses a special version of qemu-kvm named qemu-kvm-rhev.
> oVirt, the upstream product of RHV, uses a rebuilt package named 
> qemu-kvm-ev.
Just to make sure there's no misunderstanding about the content of these 
special versions of the qemu-kvm package, I wanted to point out that the 
qemu-kvm-rhev/qemu-kvm-ev used by RHV/oVirt (and also OpenStack) are 
actually *closer* to upstream qemu, not further away, than the standard 
qemu-kvm package in the same release of RHEL/CentOS. Everything in *all* 
the different builds of the package is upstream, but the -rhev/-ev 
versions of the packages have a more aggressive rebase-from-upstream 
schedule, and also have more not-yet-in-the-rebase features that are 
backported from later upstream releases. The result is that the standard 
RHEL/CentOS qemu-kvm package is more stable (since it mostly only gets 
bugfixes), while the -rhev/-ev packages have more new features (at the 
risk of encountering regressions due to the new code in those features)

Backporting of new features to a downstream release can sometimes mean 
that a feature not present in qemu-kvm-x.y.z upstream *is* present in 
qemu-kvm-rhev-x.y.z, so looking at the upstream documentation might lead 
you to believe the package you're using doesn't have feature X, when 
actually it does. But before that can happen, the feature must have 
already gone upstream and be available there (just in a slightly 
higher-numbered, but earlier-released, version). "Upstream first"
isn't
just a nice idea, it's the rule (and a way of life)! :-)