On 2/14/20 11:17 AM, Gianluca Cecchi wrote:
On Fri, Feb 14, 2020 at 4:54 PM Lentes, Bernd
<bernd.len...@helmholtz-muenchen.de
<mailto:bernd.len...@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)! :-)
