The aim of domaincapstest is to check domain capabilities XML
with respect to qemu capabilities. And we used to have old qemu
capabilities where only TPM-1.2 was supported. But as of
v12.4.0-rc1~130 QEMU-7.2 or newer is required which means the
code that's handling older QEMUs is required no more. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virsh domifannounce is a thin wrapper around the new API
virDomainAnnounceInterface(). Syntax:
virsh domifannounce guestname [interfacename] [parameters]
where the optional interfacename can be either the MAC address of the
interface to announce, or the name of the tap device used to connect
the domain's interface to the real network (if the connection is with
a tap device), and [parameters] is one or more of the following options:
--initial [unsigned integer]
--max [unsigned integer]
--rounds [unsigned integer]
--step [unsigned integer]
For example:
virsh domifannounce myguest 52:54:00:BE:EF:E1 --initial 100
virsh domifannounce other vnet2
virsh domifannounce myguest
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
using qemuMonitorAnnounceSelf(). Note that the other public domain
interface APIs expect interface to be specified by either its "target"
name (i.e. the name of the tap/macvtap device on the host) or by the
MAC address, but qemuMonitorAnnounceSelf() expects the QEMU "device
id" (which is known in libvirt as the "alias"), so we have to convert.
Resolves: https://redhat.atlassian.net/browse/RHEL-7047
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This API provides a way for a libvirt client to force a guest to
inject a "Gratuitous ARP" packet into the outgoing stream of one, or
all, network devices of the guest; this will be used to update the
forwarding tables of any network switches in the local broadcast
domain so that they will begin forwarding traffic correctly in a more
timely manner after network topology changes.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This new function sends the command "announce-self" to QEMU, causing
it to inject a series of gratuitous ARP (GARP) response packets into
the output stream of one or all guest interfaces, which will force any
switches in the same collision domain to update their forwarding db
for that interface's MAC address.
There are several parameters that control which interfaces the GARP
packets are sent on, as well as their number and interval, but all of
these parameters have sane defaults (even though QEMU's own
self-announce requires they all be specified in the QMP command).
Here is an example of the fully formed JSON for an announce-self:
{"execute":"announce-self",
"arguments":{"interfaces":["net1"],
"initial":50,
"max":550,
"rounds":5,
"step":50},
"id":"libvirt-16"}
All parameters except "interface" are unsigned integers that are
mandatory in the JSON command sent to QEMU. libvirt's
qemuMonitoAnnounceSelf() function, however, makes them optional by
replacing anything set to 0 with the same default value used
internally by QEMU when it is executing announce-self for a guest at
the end of a migration (initial=50, max=550, rounds-5, step=50).
"interfaces" (the only optional parameter from QEMU's point of view)
is (again, from QEMU's PoV) a *list* of the QEMU device-ids for the
interfaces to announce (if it's missing then announce-self injects
announcements on *all* of this guest's interfaces), but it seems much
more likely that someone will either want to announce a single
interface, or all of them, so to simplify calling in the more common
cases, our function just accepts a *single* device name (that can be
NULL) and creates a JSON array containing that one interface name (in
the rare case that someone wants to announce multiple interfaces but
not all of them, they can call our API multiple times).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add xml2argv tests verifying the standalone VNC feature:
- graphics-vnc-standalone: when both <graphics type='dbus'/> and
<graphics type='vnc'/> are present, the -vnc QEMU argument is
omitted since qemu-vnc handles VNC externally via D-Bus.
- graphics-vnc-standalone-socket: same behavior with a Unix socket
listen address.
- graphics-vnc-standalone-p2p: when dbus is p2p mode, standalone
VNC is NOT triggered and the built-in -vnc argument is preserved.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Route the OpenGraphics, OpenGraphicsFD, and GraphicsReload driver
APIs through the standalone qemu-vnc D-Bus interface when active.
Client connections are passed via D-Bus fd-passing (AddClient),
certificate reloading uses the ReloadCertificates method, and
password changes use SetPassword.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When both a D-Bus display and a VNC graphics device are configured
and the qemu-vnc binary is available, use the standalone VNC server
instead of QEMU's built-in VNC.
During domain preparation, detect whether the standalone VNC path
applies and allocate the qemuVnc context. Skip the built-in -vnc
command line argument when standalone VNC is active. Start and stop
the qemu-vnc process through the external device hooks.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add helpers to manage the standalone qemu-vnc VNC server process.
The qemu-vnc server connects to QEMU via the D-Bus display interface,
providing VNC access decoupled from the QEMU process.
The helper handles process lifecycle (start/stop), D-Bus name
watching, and provides D-Bus methods for password management,
certificate reloading, and client connections.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add qemu_vnc configuration entry to specify the path to the
standalone qemu-vnc binary.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a state directory for the standalone qemu-vnc process, following
the same pattern used for the RDP state directory.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When Hyper-V is configured to expose virtualization extensions to a
guest, report this in the domain XML by adding the vendor-appropriate
CPU feature flag:
- Intel hosts: <feature policy='require' name='vmx'/>
- AMD hosts: <feature policy='require' name='svm'/>
This requires adding ExposeVirtualizationExtensions and several other
fields introduced in Windows 10 to the Msvm_ProcessorSettingData WMI
class definition.
Resolves: https://redhat.atlassian.net/browse/RHEL-159129
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make the 'name' parameter optional and return all processors from the
host if name is not specified.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We were checking the output pointer for NULL rather than checking the
dereferenced value for NULL. So the case where no processors were
returned would not have returned an error as expected.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The dump is based on QEMU commit 'v11.0.0-1600-g5611a9268d'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The dump is based on QEMU commit 'v11.0.0-1600-g5611a9268d'
Notable changes:
- machine types for the 11.1.0 release added
- (auto) deprecated 8.1 machine type
- 'poll-weight' property added for 'iothread' object
- 'clipboard' property added for 'gtk' display backend
- 'vhost-user-rtc' device added
- new CPU models/versions
- Cascadelake-Server-v6-x86_64-cpu
- Cascadelake-Server-v7-x86_64-cpu
- ClearwaterForest-v4-x86_64-cpu
- DiamondRapids-v2-x86_64-cpu
- EPYC-Genoa-v3-x86_64-cpu
- EPYC-Milan-v4-x86_64-cpu
- EPYC-Turin-v2-x86_64-cpu
- GraniteRapids-v6-x86_64-cpu
- GraniteRapids-v7-x86_64-cpu
- Icelake-Server-v8-x86_64-cpu
- Icelake-Server-v9-x86_64-cpu
- SapphireRapids-v7-x86_64-cpu
- SapphireRapids-v8-x86_64-cpu
- SierraForest-v6-x86_64-cpu
- Skylake-Server-v6-x86_64-cpu
- 'query-kvm' command is now deprecated
- removed 'gluster' blockdev backend
- 'blkdebug' blockdev backend allows injecting delays
- chardev backends support 'encoding' property
- 'remaining' amount reported in 'query-migrate'
- 'target-info-x86_64' QOM type added
- 'x-rdma-chunk-size' migration parameter added
The few changed '.args' files update the machine type to the actual
version because they were frozen before we've added a newer capability
dump (latest machine type is masked to stabilize test outputs).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemu-11.1 will drop support for the 'gluster' block backend driver. We
want to keep the tests around to validate that nothing in the
parser/generator has changed but there's no point in wiring up QMP
schema validation against older versions.
Skip the schema validation for gluster qemublocktests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Drop the job definitions now that Cirrus CI was removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Cirrus CI no longer exists. Drop the current jobs using it from the
definitions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The arch-capabilities MSR is not defined on AMD CPUs, but KVM has always
been emulating them. Unfortunately, this may cause Windows to crash so
QEMU (since 10.1, commit d3a24134e37d57abd3e7445842cda2717f49e96d)
decided to mask the MSR by default with some additional compatibility
code for older machine types.
This is all mostly transparent except for probing when we run QEMU
without a machine type and expand the "host" CPU model. With QEMU 10.1
and newer none of the arch-capabilities features will be shown as
enabled, which may cause unexpected issues for users (such as KubeVirt)
that get the list of all supported features from the host-model CPU
definition in domain capabilities to select possible target nodes for
migration. As a result of the change, no AMD host with new QEMU will be
shown as available for incoming migration from older hosts.
Since the features are supported on the host (it's possible to
explicitly enable them), but they should not be enabled by default in
host-model CPU, we only add the to domain capabilities when
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag is set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The option corresponds to the
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES API flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Some CPU features may be enabled explicitly, but should not
automatically become part of a host-model CPU. Users can now request
such features to be shown in the host-model CPU in domain capabilities
by VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The flag is designed for expanding the CPU model used by host-model. But
the documentation was sometimes describing it as showing all CPU
features supported on the host, which is wrong as the host may support
features that would not be enabled in host-model.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This new API can be used to update an existing CPU definition with
features described by CPU data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This just makes the relevant part of virCPUx86GetHost reusable in other
places.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The function will later be called when probing QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When probing host model CPU we already expand it to get a list of all
CPU features. Let's store the expanded CPU definition in virQEMUCaps and
copy it to domain capabilities when requested by the
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES flag instead of
expanding the CPU over and over on each request.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Expanding a CPU model always produces a sorted list of features so the
features in host-model CPU capabilities were either sorted or not
depending on flags passed to virConnectGetDomainCapabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We will need to generate the capabilities in a different way based on
the flags.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Each CPU mode is filled in its own dedicated function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Separate the sorting code from virCPUExpandFeatures into a standalone
function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This drops Debian 12 and introduces Debian 13, since Debian 12
reached its EOL on 2026-06-10 [1]. However, Debian 13 dropped
official support for mipsel and mips64el, but introduced riscv64
support. Reflect this changes in supported arches in the manifest
file and regenerate with the latest lcitool.
1: https://www.debian.org/releases/
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Improved formatting of the shell output of the
function showDomains based on length of the longest domain.
Signed-off-by: Daniel Hora <dhora@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This implementation is identical to the one found in the qemu driver.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virDomainFSInfoFormat() and qemuAgentFSInfoToPublic() function
implementations are not driver dependent and can be shared across
drivers, so move them to a common place to avoid code duplication.
Also, rename virDomainFSInfoFormat() to qemuAgentFSInfoFormat() to follow
the naming scheme in qemu_agent.c.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend bhyveDomainInterfaceAddresses() to support
the VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT source.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move all the helpers to the beginning for the file to
be able to use them in every API implementation.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Sections about resource limits are currently placed across the file
in between various device examples. To make it easier to follow,
group them into a single section. This also allows to give
an introduction on the rctl(8) framework once instead of repeating
it for every resource type.
Also, document the memory limitation support added in libvirt 12.4.0.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The time_t type can be 32bit or 64bit signed integer. There are
systems where it's defined as long, or long long (32bit systems
usually). Therefore, using just 'l' length modifier is not good
enough. Also, using 'u' conversion specifier is also wrong
(though, values stored in qemuNbdkitCaps struct reflect mtime of
some files, so there won't be a negative value).
Anyway, do what we already do for virQEMUCaps - use '%lld' printf
format and typecast to long long.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When running qemuxmlconftest under valgrind, it fails with a
symbol lookup error:
valgrind: symbol lookup error: libvirt.git/_build/tests/libqemuxml2argvmock.so: undefined symbol: virTestMakeDummyFD
This occurs because qemuxml2argvmock uses the
virTestMakeDummyFD() function (implemented in testutils.c) but
does not explicitly link against test_utils_lib. Fix this by
linking the test utils library to the mock library, statically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Daniel P. Berrangé
Michal Privoznik
Laine Stump
Marc-André Lureau
Jonathon Jongsma
Peter Krempa
Jiri Denemark
Daniel Hora
Roman Bogorodskiy