can hotplug vcpus to running Windows 10 guest, but not unplug

Laine Stump laine at
Mon Feb 17 18:00:30 UTC 2020

On 2/14/20 11:17 AM, Gianluca Cecchi wrote:
> On Fri, Feb 14, 2020 at 4:54 PM Lentes, Bernd 
> <bernd.lentes at 
> <mailto:bernd.lentes at>> wrote:
>     qemu-kvm-2.11.2-5.18.1.x86_64
> [...]
>     I found a table on
>     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)! :-)

More information about the libvirt-users mailing list