docs/manpages/virsh.rst | 27 ++++++ include/libvirt/libvirt-host.h | 13 +++ src/driver-hypervisor.h | 17 ++++ src/libvirt-host.c | 109 +++++++++++++++++++++++ src/libvirt_public.syms | 2 + src/qemu/qemu_driver.c | 105 ++++++++++++++++++++++ src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 3 + src/remote/remote_daemon_dispatch.c | 76 ++++++++++++++++ src/remote/remote_driver.c | 100 +++++++++++++++++++++ src/remote/remote_protocol.x | 37 +++++++- src/remote_protocol-structs | 27 ++++++ tools/virsh-host.c | 132 ++++++++++++++++++++++++++++ 14 files changed, 650 insertions(+), 1 deletion(-)
libvirt and qemu cpu models are out of sync. libvirt cpu models are
considered static and never changing, whereas qemu cpu models have
changed over time. This leads to problems and confusion for users,
as the cpu models they specify may have different features than what
they expect.
This series introduces two new APIs to enumerate and retrieve cpu
models dynamically from the hypervisor at runtime, allowing the user
to make use of cpu models from newer hypervisor versions even if
libvirt is not aware of them.
These two new functions are intended as building blocks onto which
higher-level functionality can be build, e.g. the ability to specify
a hypervisor cpu model directly in a domain xml. With these two
functions alone this has to be done manually for now, i.e. enumerate
the available cpu models, retrieve the cpu description and manually
insert it into the domain xml accordingly:
$ virsh hypervisor-cpu-models --arch x86_64
Name Alias
----------------------------------------------------
max
host
base
qemu64-v1
qemu64 qemu64-v1
qemu32-v1
qemu32 qemu32-v1
phenom-v1
phenom phenom-v1
(...)
$ virsh hypervisor-cpu-definition --machine pc --arch x86_64 qemu64
<cpu>
<model>qemu64</model>
<feature name='cmov'/>
<feature name='mmx'/>
<feature name='xd'/>
<feature name='x-intel-pt-auto-level'/>
<feature name='kvm_asyncpf'/>
<feature name='kvm-asyncpf'/>
<feature name='legacy-cache'/>
<feature name='vmware-cpuid-freq'/>
<feature name='mce'/>
<feature name='mca'/>
<feature name='msr'/>
<feature name='fxsr'/>
<feature name='cpuid-0xb'/>
<feature name='kvm_pv_eoi'/>
<feature name='pni'/>
<feature name='x2apic'/>
<feature name='i64'/>
<feature name='pae'/>
<feature name='pat'/>
<feature name='sse'/>
<feature name='kvm_nopiodelay'/>
<feature name='kvm-nopiodelay'/>
<feature name='kvmclock-stable-bit'/>
<feature name='hypervisor'/>
<feature name='syscall'/>
<feature name='x-migrate-smi-count'/>
<feature name='full-cpuid-auto-level'/>
<feature name='sse3'/>
<feature name='sse2'/>
<feature name='kvm-pv-eoi'/>
<feature name='cx8'/>
<feature name='pge'/>
<feature name='fill-mtrr-mask'/>
<feature name='cx16'/>
<feature name='de'/>
<feature name='clflush'/>
<feature name='tsc'/>
<feature name='fpu'/>
<feature name='check'/>
<feature name='apic'/>
<feature name='kvm-steal-time'/>
<feature name='kvm_steal_time'/>
<feature name='kvmclock'/>
<feature name='l3-cache'/>
<feature name='nx'/>
<feature name='tcg-cpuid'/>
<feature name='lm'/>
<feature name='pse'/>
<feature name='sep'/>
<feature name='kvm'/>
<feature name='lahf-lm'/>
<feature name='lahf_lm'/>
<feature name='mtrr'/>
<feature name='pse36'/>
</cpu>
The returned cpu description is currently completely unfiltered, as
can be seen by the duplicate entries differing only in "-" vs. "_"
usage, inclusion of experimental feature flags and generally, flags
that are not recognized by libvirt. One possibility to adress this
would be to extend virQEMUCapsCPUFeatureTranslate.
Before I continue with this, I would love to hear other people's
thoughts, comments and potential use cases.
Cheers,
Tim
Tim Wiederhake (9):
qemuMonitorCPUDefInfo: Add alias
libvirt: introduce virConnectGetHypervisorCPUModelNames public API
remote: Add RPC support for the virConnectGetHypervisorCPUModelNames
API
qemu: implement virConnectGetHypervisorCPUModelNames API
tools: Report hypervisor cpu model names
libvirt: introduce virConnectGetHypervisorCPUModelDefinition public
API
remote: Add support for the virConnectGetHypervisorCPUModelDefinition
API
qemu: Implement virConnectGetHypervisorCPUModelDefinition API
tools: Report hypervisor cpu model definitions
docs/manpages/virsh.rst | 27 ++++++
include/libvirt/libvirt-host.h | 13 +++
src/driver-hypervisor.h | 17 ++++
src/libvirt-host.c | 109 +++++++++++++++++++++++
src/libvirt_public.syms | 2 +
src/qemu/qemu_driver.c | 105 ++++++++++++++++++++++
src/qemu/qemu_monitor.c | 2 +
src/qemu/qemu_monitor.h | 1 +
src/qemu/qemu_monitor_json.c | 3 +
src/remote/remote_daemon_dispatch.c | 76 ++++++++++++++++
src/remote/remote_driver.c | 100 +++++++++++++++++++++
src/remote/remote_protocol.x | 37 +++++++-
src/remote_protocol-structs | 27 ++++++
tools/virsh-host.c | 132 ++++++++++++++++++++++++++++
14 files changed, 650 insertions(+), 1 deletion(-)
--
2.31.1
See below. What do the more experienced libvirt developers think, is this going in the right direction? Thanks, Tim On Tue, 2022-06-28 at 18:09 +0200, Tim Wiederhake wrote: > libvirt and qemu cpu models are out of sync. libvirt cpu models are > considered static and never changing, whereas qemu cpu models have > changed over time. This leads to problems and confusion for users, > as the cpu models they specify may have different features than what > they expect. > > This series introduces two new APIs to enumerate and retrieve cpu > models dynamically from the hypervisor at runtime, allowing the user > to make use of cpu models from newer hypervisor versions even if > libvirt is not aware of them. > > These two new functions are intended as building blocks onto which > higher-level functionality can be build, e.g. the ability to specify > a hypervisor cpu model directly in a domain xml. With these two > functions alone this has to be done manually for now, i.e. enumerate > the available cpu models, retrieve the cpu description and manually > insert it into the domain xml accordingly: > > $ virsh hypervisor-cpu-models --arch x86_64 > Name Alias > ---------------------------------------------------- > max > host > base > qemu64-v1 > qemu64 qemu64-v1 > qemu32-v1 > qemu32 qemu32-v1 > phenom-v1 > phenom phenom-v1 > (...) > > $ virsh hypervisor-cpu-definition --machine pc --arch x86_64 > qemu64 > <cpu> > <model>qemu64</model> > <feature name='cmov'/> > <feature name='mmx'/> > <feature name='xd'/> > <feature name='x-intel-pt-auto-level'/> > <feature name='kvm_asyncpf'/> > <feature name='kvm-asyncpf'/> > <feature name='legacy-cache'/> > <feature name='vmware-cpuid-freq'/> > <feature name='mce'/> > <feature name='mca'/> > <feature name='msr'/> > <feature name='fxsr'/> > <feature name='cpuid-0xb'/> > <feature name='kvm_pv_eoi'/> > <feature name='pni'/> > <feature name='x2apic'/> > <feature name='i64'/> > <feature name='pae'/> > <feature name='pat'/> > <feature name='sse'/> > <feature name='kvm_nopiodelay'/> > <feature name='kvm-nopiodelay'/> > <feature name='kvmclock-stable-bit'/> > <feature name='hypervisor'/> > <feature name='syscall'/> > <feature name='x-migrate-smi-count'/> > <feature name='full-cpuid-auto-level'/> > <feature name='sse3'/> > <feature name='sse2'/> > <feature name='kvm-pv-eoi'/> > <feature name='cx8'/> > <feature name='pge'/> > <feature name='fill-mtrr-mask'/> > <feature name='cx16'/> > <feature name='de'/> > <feature name='clflush'/> > <feature name='tsc'/> > <feature name='fpu'/> > <feature name='check'/> > <feature name='apic'/> > <feature name='kvm-steal-time'/> > <feature name='kvm_steal_time'/> > <feature name='kvmclock'/> > <feature name='l3-cache'/> > <feature name='nx'/> > <feature name='tcg-cpuid'/> > <feature name='lm'/> > <feature name='pse'/> > <feature name='sep'/> > <feature name='kvm'/> > <feature name='lahf-lm'/> > <feature name='lahf_lm'/> > <feature name='mtrr'/> > <feature name='pse36'/> > </cpu> > > The returned cpu description is currently completely unfiltered, as > can be seen by the duplicate entries differing only in "-" vs. "_" > usage, inclusion of experimental feature flags and generally, flags > that are not recognized by libvirt. One possibility to adress this > would be to extend virQEMUCapsCPUFeatureTranslate. > > Before I continue with this, I would love to hear other people's > thoughts, comments and potential use cases. > > Cheers, > Tim > > Tim Wiederhake (9): > qemuMonitorCPUDefInfo: Add alias > libvirt: introduce virConnectGetHypervisorCPUModelNames public API > remote: Add RPC support for the > virConnectGetHypervisorCPUModelNames > API > qemu: implement virConnectGetHypervisorCPUModelNames API > tools: Report hypervisor cpu model names > libvirt: introduce virConnectGetHypervisorCPUModelDefinition public > API > remote: Add support for the > virConnectGetHypervisorCPUModelDefinition > API > qemu: Implement virConnectGetHypervisorCPUModelDefinition API > tools: Report hypervisor cpu model definitions > > docs/manpages/virsh.rst | 27 ++++++ > include/libvirt/libvirt-host.h | 13 +++ > src/driver-hypervisor.h | 17 ++++ > src/libvirt-host.c | 109 +++++++++++++++++++++++ > src/libvirt_public.syms | 2 + > src/qemu/qemu_driver.c | 105 ++++++++++++++++++++++ > src/qemu/qemu_monitor.c | 2 + > src/qemu/qemu_monitor.h | 1 + > src/qemu/qemu_monitor_json.c | 3 + > src/remote/remote_daemon_dispatch.c | 76 ++++++++++++++++ > src/remote/remote_driver.c | 100 +++++++++++++++++++++ > src/remote/remote_protocol.x | 37 +++++++- > src/remote_protocol-structs | 27 ++++++ > tools/virsh-host.c | 132 > ++++++++++++++++++++++++++++ > 14 files changed, 650 insertions(+), 1 deletion(-) > > -- > 2.31.1 > >
On Tue, Jun 28, 2022 at 06:09:37PM +0200, Tim Wiederhake wrote:
> libvirt and qemu cpu models are out of sync. libvirt cpu models are
> considered static and never changing, whereas qemu cpu models have
> changed over time. This leads to problems and confusion for users,
> as the cpu models they specify may have different features than what
> they expect.
>
> This series introduces two new APIs to enumerate and retrieve cpu
> models dynamically from the hypervisor at runtime, allowing the user
> to make use of cpu models from newer hypervisor versions even if
> libvirt is not aware of them.
>
> These two new functions are intended as building blocks onto which
> higher-level functionality can be build, e.g. the ability to specify
> a hypervisor cpu model directly in a domain xml. With these two
> functions alone this has to be done manually for now, i.e. enumerate
> the available cpu models, retrieve the cpu description and manually
> insert it into the domain xml accordingly:
This series only reports the new CPU models/features. I'm not seeing
any changes to allow the user to actually use them in a new VM, as
libvirt rejects models it doesn't know of:
# virsh edit demo
...
<cpu mode='custom' match='exact' check='partial'>
<model fallback='allow'>Nehalem-v1</model>
</cpu>
# virsh start demo
error: Failed to start domain 'demo'
error: internal error: Unknown CPU model Nehalem-v1
> $ virsh hypervisor-cpu-models --arch x86_64
> Name Alias
> ----------------------------------------------------
> max
> host
> base
> qemu64-v1
> qemu64 qemu64-v1
> qemu32-v1
> qemu32 qemu32-v1
> phenom-v1
> phenom phenom-v1
> (...)
>
> $ virsh hypervisor-cpu-definition --machine pc --arch x86_64 qemu64
> <cpu>
> <model>qemu64</model>
> <feature name='cmov'/>
> <feature name='mmx'/>
> <feature name='xd'/>
> <feature name='x-intel-pt-auto-level'/>
> <feature name='kvm_asyncpf'/>
> <feature name='kvm-asyncpf'/>
> <feature name='legacy-cache'/>
> <feature name='vmware-cpuid-freq'/>
> <feature name='mce'/>
> <feature name='mca'/>
> <feature name='msr'/>
> <feature name='fxsr'/>
> <feature name='cpuid-0xb'/>
> <feature name='kvm_pv_eoi'/>
> <feature name='pni'/>
> <feature name='x2apic'/>
> <feature name='i64'/>
> <feature name='pae'/>
> <feature name='pat'/>
> <feature name='sse'/>
> <feature name='kvm_nopiodelay'/>
> <feature name='kvm-nopiodelay'/>
> <feature name='kvmclock-stable-bit'/>
> <feature name='hypervisor'/>
> <feature name='syscall'/>
> <feature name='x-migrate-smi-count'/>
> <feature name='full-cpuid-auto-level'/>
> <feature name='sse3'/>
> <feature name='sse2'/>
> <feature name='kvm-pv-eoi'/>
> <feature name='cx8'/>
> <feature name='pge'/>
> <feature name='fill-mtrr-mask'/>
> <feature name='cx16'/>
> <feature name='de'/>
> <feature name='clflush'/>
> <feature name='tsc'/>
> <feature name='fpu'/>
> <feature name='check'/>
> <feature name='apic'/>
> <feature name='kvm-steal-time'/>
> <feature name='kvm_steal_time'/>
> <feature name='kvmclock'/>
> <feature name='l3-cache'/>
> <feature name='nx'/>
> <feature name='tcg-cpuid'/>
> <feature name='lm'/>
> <feature name='pse'/>
> <feature name='sep'/>
> <feature name='kvm'/>
> <feature name='lahf-lm'/>
> <feature name='lahf_lm'/>
> <feature name='mtrr'/>
> <feature name='pse36'/>
> </cpu>
>
> The returned cpu description is currently completely unfiltered, as
> can be seen by the duplicate entries differing only in "-" vs. "_"
> usage, inclusion of experimental feature flags and generally, flags
> that are not recognized by libvirt. One possibility to adress this
> would be to extend virQEMUCapsCPUFeatureTranslate.
The duplicated feature names are really bad IMHO, as as the (few)
cases where QEMU names diverge from libvirt names.
I don't mind us exposing CPU versions that we don't have in our
XML database, but directly exposing new features and base CPU
models IMHO is not desirable. A really key point of libvirt is
to define a (thin) abstraction over the hypervisor, not blindly
expose its low level platform specific terminology.
> Before I continue with this, I would love to hear other people's
> thoughts, comments and potential use cases.
Before we actually add these APIs we need to actually be able to
use the resulting CPU models to run guests, otherwise there's
nothing useful that can be done with this new information reported.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.