Chun Feng Wu [Wed, 19 Feb 2025 16:57:09 +0000 (22:27 +0530)]
qemu: monitor: Add support for ThrottleGroup operations
This change contains QMP requests for ThrottleGroup
* ThrottleGroup is updated through "qemuMonitorJSONUpdateThrottleGroup"
* ThrottleGroup is retrieved through "qemuMonitorJSONGetThrottleGroup"
* ThrottleGroup is deleted by reusing "qemuMonitorDelObject"
* ThrottleGroup is added by reusing "qemuMonitorAddObject"
* "qemuMonitorMakeThrottleGroupLimits" will be used by building qemu cmd as well
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* change throttle group config conversions P to U allow zero.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Deleted all getter code.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Chun Feng Wu [Wed, 19 Feb 2025 16:57:08 +0000 (22:27 +0530)]
config: Introduce ThrottleFilter and corresponding XML parsing
Introduce throttle filter along with corresponding operations.
* Define new struct 'virDomainThrottleFilterDef' and corresponding destructor
* Update _virDomainDiskDef to include virDomainThrottleFilterDef
* Support throttle filter "Parse" and "Format" for operations between DOM XML
and structs. Note, this commit just contains parse/format of group name for
throttle filter in domain_conf.c, there is other commit to handle throttle
filter nodename parse/format between throttlefilter and diskPrivateData for
statusxml in qemu_domain.c when processing qemuDomainDiskPrivate and
qemuDomainDiskPrivate
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Error handling for null throttle group.
* Update of code documentation comments.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Fixed naming of virDomainThrottleFilterDefClear to ...Free
* Fixed memleak of the throttle filter definitions
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Chun Feng Wu [Wed, 19 Feb 2025 16:57:07 +0000 (22:27 +0530)]
config: Introduce ThrottleGroup and corresponding XML parsing
Introduce throttlegroup into domain and provide corresponding methods
* Define new struct 'virDomainThrottleGroupDef' and corresponding destructor
* Add operations(Add, Update, Del, ByName, Copy, Free) for 'virDomainThrottleGroupDef'
* Update _virDomainDef to include virDomainThrottleGroupDef
* Support new resource "Parse" and "Format" for operations between struct and DOM XML
* Make sure "group_name" is defined in xml
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Validation check for zero throttle groups.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Chun Feng Wu [Wed, 19 Feb 2025 16:57:06 +0000 (22:27 +0530)]
schema: Add new domain elements to support multiple throttle filters
Introduce schema for defining '<throttlefilters>' element which
references throttling groups to form filter chain in qemu for specific
disk
* Add new elements '<throttlefilters>'
* <ThrottleFilters> can include multiple throttlegroup references to
form filter chain in qemu
* Chained throttle filters feature in qemu is described at
https://gitlab.com/qemu-project/qemu/blob/master/docs/throttle.txt
Signed-off-by: Chun Feng Wu <danielwuwy@163.com> Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Chun Feng Wu [Wed, 19 Feb 2025 16:57:05 +0000 (22:27 +0530)]
schema: Add new domain elements to support multiple throttle groups
Introduce schema for defining '<throttlegroups>' element which
configures throttling groups which can be configured for multiple
disks.
* Refactor "diskIoTune" to extract common schema "iotune"
* Add new elements '<throttlegroups>'
* <ThrottleGroups> contains <ThrottleGroup> defintion, which references
"iotune"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com> Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
David Judkovics [Thu, 20 Mar 2025 05:28:24 +0000 (01:28 -0400)]
virsh: Introduce new hypervisor-cpu-models command
Add new virsh command 'hypervisor-cpu-models'. Command pulls from the
existing domcapabilities XML and uses xpath to parse CPU model strings.
By default, only models reported as usable by the hypervisor on the
host system are printed. User may specify "--all" to also print
models which are not supported on the host.
Signed-off-by: David Judkovics <djudkovi@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
hypervisor: emit systemd status & log messages while saving
Since processing running VMs on OS shutdown can take a while, it is
beneficial to send systemd status messages about the progress.
The systemd status is a point-in-time message, with no ability to
look at the history of received messages. So in the systemd status
we include the progress information. For the same reason there is
no benefit in sending failure messages, as they'll disappear as soon
as a status is sent for the subsequent VM to be processed.
The libvirt log statements can be viewed as a complete log record
so don't need progress info, but do include warnings about failures
(present from earlier commits).
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
rpc: don't let systemd shutdown daemon while saving VMs
The service unit "TimeoutStopSec" setting controls how long systemd
waits for a service to stop before aggressively killing it, defaulting
to 30 seconds if not set.
When we're processing shutdown of VMs in response to OS shutdown, we
very likely need more than 30 seconds to complete this job, and can
not stop the daemon during this time.
To avoid being prematurely killed, setup a timer that repeatedly
extends the "TimeoutStopSec" value while stop of running VMs is
arranged.
This does mean if libvirt hangs while stoppping VMs, systemd won't
get to kill the libvirt daemon, but this is considered less harmful
that forcefully killing running VMs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The daemons are wired up to shutdown in responsible to UNIX process
signals, as well as in response to login1 dbus signals, or loss of
desktop session. The latter two options can optionally preserve state
(ie running VMs).
In non-systemd environments, as well as for testing, it would be useful
to have a way to trigger shutdown with state preservation more directly.
Thus a new admin protocol API is introduced
virAdmConnectDaemonShutdown
which will trigger a daemon shutdown, and preserve running VMs if the
VIR_DAEMON_SHUTDOWN_PRESERVE flag is set.
It has a corresponding 'virt-admin daemon-shutdown [--preserve]' command
binding.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The preserving of state (ie running VMs) requires a fully functional
daemon and hypervisor driver. If any part has started shutting down
then saving state may fail, or worse, hang.
The current shutdown sequence does not guarantee safe ordering, as
we synchronize with the state saving thread only after the hypervisor
driver has had its 'shutdownPrepare' callback invoked. In the case of
QEMU this means that worker threads processing monitor events may well
have been stopped.
This implements a full state machine that has a well defined ordering
that an earlier commit documented as the desired semantics.
With this change, nothing will start shutting down if the state saving
thread is still running.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
rpc: don't unconditionally quit after preserving state
The call to preserve state (ie running VMs) is triggered in response to
the desktop session dbus terminating (session daemon), or logind sending
a "PrepareForShutdown" signal. In the case of the latter, daemons
should only save their state, not actually exit yet. Other things on the
system may still expect the daemon to be running at this stage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the remote daemon code is responsible for calling virStateStop
in a background thread. The virNetDaemon code wants to synchronize with
this during shutdown, however, so the virThreadPtr must be passed over.
Even the limited synchronization done currently, however, is flawed and
to fix this requires the virNetDaemon code to be responsible for calling
virStateStop in a thread more directly.
Thus the logic is moved over into virStateStop via a further callback
to be registered by the remote daemon.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: clarify semantics of the various virStateNNN methods
It is not documented what the various virStateNNN methods are each
responsible for doing and the names give little guidance either.
Provide some useful documentation comments to explain the intended
usage of each.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qemu: add config to control if auto-shutdown VMs are restored
If shutting down running VMs at host shutdown, it can be useful to
automatically start them again on next boot. This adds a config
parameter 'auto_shutdown_restore', which defaults to enabled, which
leverages the autostart once feature.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
hypervisor: wire up support for auto restore of running domains
When performing auto-shutdown of running domains, there is now the
option to mark them as "autostart once", so that their state is
restored on next boot. This applies on top of the traditional
autostart flag.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
conf: implement support for autostart once feature
This is maintained in the same way as the autostart flag, using a
symlink. The difference is that instead of '.xml', the symlink
suffix is '.xml.once'.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
src: add new APIs for marking a domain to autostart once
When a domain is marked for autostart, it will be started on every
subsequent host OS boot. There may be times when it is desirable to
mark a domain to be autostarted, on the next boot only.
Thus we add virDomainSetAutostartOnce / virDomainGetAutostartOnce.
An alternative would have been to overload the existing
virDomainSetAutostart method, to accept values '1' or '2' for
the autostart flag. This was not done because it is expected
that language bindings will have mapped the current autostart
flag to a boolean, and thus turning it into an enum would create
a compatibility problem.
A further alternative would have been to create a new method
virDomainSetAutostartFlags, with a VIR_DOMAIN_AUTOSTART_ONCE
flag defined. This was not done because it is felt desirable
to clearly separate the two flags. Setting the "once" flag
should not interfere with existing autostart setting, whether
it is enabled or disabled currently.
The 'virsh autostart' command, however, is still overloaded
by just adding a --once flag, while current state is added
to 'virsh dominfo'.
No ability to filter by 'autostart once' status is added to
the domain list APIs. The most common use of autostart once
will be to automatically set it on host shutdown, and it be
cleared on host startup. Thus there would rarely be scenarios
in which a running app will need to filter on this new flag.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
hypervisor: custom shutdown actions for transient vs persistent VMs
It may be desirable to treat transient VMs differently from persistent
VMs. For example, while performing managed save on persistent VMs makes
sense, the same not usually true of transient VMs, since by their
nature they will have no config to restore from.
This also lets us fix a long standing problem with incorrectly
attempting to perform managed save on transient VMs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The auto shutdown code can currently only perform managed save,
which may fail in some cases, for example when PCI devices are
assigned. On failure, shutdown inhibitors remain in place which
may be undesirable.
This expands the logic to try a sequence of operations
* Managed save
* Graceful shutdown
* Forced poweroff
Each of these operations can be enabled or disabled, but they
are always applied in this order.
With the shutdown option, a configurable time is allowed for
shutdown to complete, defaulting to 30 seconds, before moving
onto the forced poweroff phase.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: always invoke virStateStop for all daemons
Currently the virStateStop method is only wired up to run save for
the unprivileged daemons, so there is no functional change.
IOW, session exit, or host OS shutdown will trigger VM managed saved
for QEMU session daemon, but not the system daemon.
This changes the daemon code to always run virStateStop for all
daemons. Instead the QEMU driver is responsible for skipping its
own logic when running privileged...for now.
This means that virStateStop will now be triggered by logind's
PrepareForShutdown signal.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 17 Mar 2025 17:18:37 +0000 (18:18 +0100)]
qemuHotplugRemoveManagedPR: Integrate check whether removal is needed
Calls to 'qemuHotplugRemoveManagedPR' needed to be guarded by a check if
the removed elements actually caused us to add the manager in the first
place.
The two new calls added in commit 1697323bfe6000c2f5a2519c06f0ba81 were
not guarded by such check and thus would spam the debug log with:
[{"id": "libvirt-59", "error": {"class": "GenericError", "desc": "object 'pr-helper0' not found"}}]
Luckily 'qemuHotplugRemoveManagedPR' didn't request the error to be
reported as a proper error.
Don't attempt the removal unless needed.
Fixes: 1697323bfe6000c2f5a2519c06f0ba81f7b792eb Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 17 Mar 2025 16:50:42 +0000 (17:50 +0100)]
qemu: Remove return value from 'qemuHotplugRemoveManagedPR'
The only place which actually checked the return value would skip code
e.g. to delete unused files or stop no longer used services. The rest of
the callers ignored the value.
As this is expected to be used on cleanup code paths which have no
possibility to report errors we should remove the return value
completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Peter Krempa [Mon, 17 Mar 2025 16:35:12 +0000 (17:35 +0100)]
qemu: Do not replace filter nodes with virDomainBlockCopy
The block copy operation is supposed to just move the disk to a new
destination. While in certain scenarios it'd make sense to drop the
copy-on-read layer, the definition would not correspond to it.
This was caused by a fix to the behaviour of the block job after
conversion to -blockdev as 'blockdev-mirror' requires the top node of
the disk to be selected. This also causes that the 'copy-on-read' filter
is ejected but libvirt doesn't unplug it.
Instead we need to use the 'replaces' argument of 'blockdev-mirror'
which allows to keep filters in place. This will preserve the
configuration (which can be optimized later) and also fixes a spurious
error logged when trying to unplug the first real file node after
copy-on-read which still looks used to qemu.
This is also needed for the upcoming feature which adds 'throttle'
filter layers as we need to keep those in place too to facilitate the
throttling.
Resolves: https://issues.redhat.com/browse/RHEL-40077 Fixes: e3137539a9c4af25ab085506d5467ec0847b0ecc Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Boris Fiuczynski [Tue, 18 Mar 2025 13:48:50 +0000 (14:48 +0100)]
qemu_domain_address: fix CCW virtio-mem hotplug
Since commit f23f8ff91a virtio-mem supports also CCW. When hotplugging a
virtio-mem device with a CCW address results in a PCI device getting
attached. The method qemuDomainAssignMemoryDeviceSlot is only
considering PCI as address type and overwriting the CCW address. Adding
support for address type CCW.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Generalize the function, broaden its potential usage.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
util: annotate non-null arguments for virGDBusCallMethod()
Helps avoid/debug a potential SEGV if conn is NULL, since gio will not
set the "gerror" in that case and we will crash later at:
virReportError(VIR_ERR_DBUS_SERVICE, "%s", gerror->message);
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
../tools/nss/libvirt_nss_macs.c:155:8: error: ‘jerr’ may be used uninitialized [-Werror=maybe-uninitialized]
155 | if (jerr == json_tokener_continue) {
| ^
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The warning is triggered when compiling with various build options, such
as -Doptimization=g.
From gcc(1) man page about -Winline:
seemingly insignificant changes in the source program can cause the warnings produced by -Winline to appear or disappear.
Such flaky behaviour is best left to the user discretion.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
src: add new target for regenerating protocol structs files
Introduce a new ninja target
ninja -C build regen-{PROTO}
eg
ninja -C build regen-admin_protocol
that will re-create the reference output file based on what the
current pdwtags command emits. A small change is made to squash
whitespace on enum declarations so that introducing a new longer
enum name doesn't trigger re-indent of all existing enum names.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
ch: Fix refcounting in virCHEventHandlerLoop() and virCHStartEventHandler()
When event handler thread is created inside of
virCHStartEventHandler() the monitor object is refed because the thread
(virCHEventHandlerLoop()) that's created in the very next step
uses it. But right after that, the monitor object is unrefed,
which is wrong because it takes away the reference which was
handed over to the thread. The monitor must be unrefed inside the
thread, when no longer needed.
And while at it, move the unref call of the domain object after
the debug print which obviously accesses the domain definition.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If starting a CH domain fails an error is reported and
virCHProcessStart() calls virCHProcessStop() to clean up any
residues. Problem is, inside of virCHProcessStop() some public
APIs might be called (e.g. virNetworkLookupByName(),
virNetworkPortLookupByUUID() and/or virNetworkPortDelete()). Per
our design, public APIs reset last error which means the useful
error reported earlier is lost.
Fix this by calling virErrorPreserveLast() + virErrorRestore()
combo inside of virCHProcessStop().
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The glib adoption docs was suggesting avoidance of certain APIs that
were obsoleted by glib, during the transition period. Now that the
referenced APIs no longer exist in libvirt code, they can also be
removed from the docs.
NB, the virStringListRemoveDuplicates method remains since there is
no glib equivalent.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Most, but not all, files in scripts have execute permission. While we
don't need this in order to launch them via meson/ninja build rules,
it is nice to direct execution if they have execution permission. This
makes the practice consistent across all scripts.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
docs: document workaround for DMARC countermeasures
If a contributor's email domain has a DMARC policy of 'p=quarantine'
or 'p=reject', mailman will apply DMARC countermeasures on all mails
sent to lists.libvirt.org rewriting the "From" header to remove the
sender's email address. e.g.
From: Your Name via <lists.libvirt.org>
If these countermeasures were not applied, affected mail would either
have gone directly to SPAM, or have been entirely rejected. Mailman3
is unable to be configured to guarantee no mangling of the mail body
so these countermeasures are unavoidable for lists.libvirt.org.
Amongst the various downsides, the From address rewriting has the
bad effect of mangling git commit author attribution.
To avoid this it is required to add two additional git config
settings:
Note, *both* are required, even if your ``format.from`` matches
your existing git identity, because the latter only takes effect
once the former is set.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Laine Stump [Fri, 7 Mar 2025 00:19:12 +0000 (19:19 -0500)]
conf: parse interface/source/@dev for all interface types (with backend type='passt')
The original implementation of the passt backend for vhost-user
interfaces erroneously forgot to parse:
<source dev='blah'/>
for interface type='vhostuser', so it wasn't being added to the passt
commandline, and also wasn't being saved to the domain config. Now we
parse it whenever the <backend> type='passt', no matter what the
interface type, and then throw an error during validation if
source/@dev was specified for interface type = 'user|vhostuser' and
backend type != 'passt'.
Fixes: 1e9054b9c79d721a55f413c2983c5370044f8f60
Resolves: https://issues.redhat.com/browse/RHEL-82539 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Stefan Berger [Mon, 16 Dec 2024 19:16:44 +0000 (14:16 -0500)]
docs: Clarify what source and name attributes of TPM profile describe
Clarify what source and name attributes of TPM profile describe and
update the version placeholder to the libvirt version when profiles
were first supported, v10.10. Also mention that profiles with prefix
'custom:' in their name can be modified.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:03:02 +0000 (13:03 +0100)]
ch: Rework virCHProcessConnectMonitor()
Firstly, let's switch from explicit virCHDriverGetConfig() +
virObjectUnref() combo to g_autoptr(virCHDriverConfig). This
leaves us with the @monitor variable which is initialized to NULL
only to be then set to the retval of virCHMonitorNew() and
returned instantly. Well, the variable is now useless and can be
dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:02:33 +0000 (13:02 +0100)]
ch: Unref @cfg in virCHProcessStop()
At the beginning of virCHProcessStop() the ref to driver config
is obtained (via virCHDriverGetConfig()), but corresponding unref
call is lacking. Use g_autoptr() to make sure the config is
unrefed always.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:02:17 +0000 (13:02 +0100)]
ch: Free @iothreads array in virCHProcessSetupIOThreads()
When the CH driver starts a domain virCHProcessSetupIOThreads()
is called eventually which in turn calls
virCHMonitorGetIOThreads(). The latter returns an array of
iothreads which is never freed leading to a memleak:
130 (104 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 1,804 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0xB3A9359: virCHMonitorGetIOThreads (ch_monitor.c:1183)
by 0xB3AA5BB: virCHProcessSetupIOThreads (ch_process.c:348)
by 0xB3AAC59: virCHProcessSetup (ch_process.c:480)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:58 +0000 (13:01 +0100)]
ch: Don't leak virCHDomainObjPrivate struct members
There are some members of the virCHDomainObjPrivate struct that
are allocated at various stages of domain lifecycle but then are
never freed:
1) cgroup - allocated in virDomainCgroupSetupCgroup()
2) autoCpuset - this one is actually never allocated (and thus is
always NULL, but soon it may be used. Just free
it for now, which is a NOP anyways.
3) autoNodeset - same story as 2).
There are two more members, which shouldn't be freed:
1) driver - this is just a raw pointer to the CH driver (see
virCHDomainObjPrivateAlloc()).
2) monitor - this member is cleared in virCHProcessStop(), way
before control even gets to
virCHDomainObjPrivateFree().
452 (400 direct, 52 indirect) bytes in 1 blocks are definitely lost in loss record 1,944 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x49479CE: virCgroupNewFromParent (vircgroup.c:893)
by 0x49481BA: virCgroupNewDomainPartition (vircgroup.c:1068)
by 0x494915E: virCgroupNewMachineManual (vircgroup.c:1378)
by 0x49492FE: virCgroupNewMachine (vircgroup.c:1432)
by 0x4B5E3DE: virDomainCgroupInitCgroup (domain_cgroup.c:377)
by 0x4B5E9CD: virDomainCgroupSetupCgroup (domain_cgroup.c:524)
by 0xB3AC693: virCHProcessStart (ch_process.c:951)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:44 +0000 (13:01 +0100)]
ch: Free retval of curl_slist_append()
There are two places where curl_slist_append() is called but
corresponding call to curl_slist_free_all() is missing:
virCHMonitorPutNoContent() and virCHMonitorGet() which leads to
memleaks:
41 (16 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 992 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7B41: virCHMonitorPutNoContent (ch_monitor.c:824)
by 0xB3A89FF: virCHMonitorBootVM (ch_monitor.c:1030)
by 0xB3AC6F1: virCHProcessStart (ch_process.c:967)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
by 0x4B28B5E: virNetServerProcessMsg (virnetserver.c:135)
88 (16 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 1,501 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7E41: virCHMonitorGet (ch_monitor.c:864)
by 0xB3A92E2: virCHMonitorGetInfo (ch_monitor.c:1157)
by 0xB3A9CEA: virCHProcessUpdateInfo (ch_process.c:142)
by 0xB3AAD36: virCHProcessSetup (ch_process.c:492)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Thu, 13 Mar 2025 12:01:19 +0000 (13:01 +0100)]
network: Free inhibitor in networkStateCleanup()
The shutdown inhibitor is created in networkStateInitialize() but
corresponding call to virInhibitorFree() is missing in
networkStateCleanup() leading to a memleak:
116 (72 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 1,769 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x4993B9B: virInhibitorNew (virinhibitor.c:152)
by 0x5279394: networkStateInitialize (bridge_driver.c:654)
by 0x4CC74DC: virStateInitialize (libvirt.c:665)
by 0x15B719: daemonRunStateInit (remote_daemon.c:613)
by 0x49F2B44: virThreadHelper (virthread.c:256)
by 0x5356662: start_thread (in /usr/lib64/libc.so.6)
by 0x53D7DA3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 12 Mar 2025 16:04:04 +0000 (17:04 +0100)]
qemu: Always assume support for QEMU_CAPS_INCREMENTAL_BACKUP
The support for incremental backup (not the backup api itself) was gated
on support for migrating bitmaps. As the ability to migrate bitmaps was
added in qemu-6.0 we can now assume that all supported qemu versions
support incremental backup.
Remove the interlocking.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
