Since the object stores the pointer to the parent class object
internally we can add the name of the class of the object to the debug
messages. Since the debug messages are based on probe points propagate
it into the probe point rather than adding separate debug message.
For virObjectUnref, this also fixes the ordering of the messages to be
'unref->dispose' by invoking the PROBE before unref rather than the
other way around which didn't make sense in the logs and wouldn't allow
accessing the class pointer from the already disposed-of object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The debug messages related to PROBE points in object handling don't
really need to be logged with the 'info' priority. Downshift them to
'debug'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The standard 'PROBE' macro uses the 'info' priority for the log entry
corresponding to the probe point. While in some cases it makes sense to
log above debug priority in others it does not. Add the possibility to
pick a lower priority level.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In the implementation of the virStream events in the remote driver, the
freeing of the passed opaque data for the callback was guarded by:
if (!cbdata->cb && cbdata->ff)
(cbdata->ff)(cbdata->opaque);
thus if the 'cb' is passed to 'virStreamEventAddCallback' the private
data would never be freed once 'virStreamEventRemoveCallback' is called.
The issue can be reproduced both in client applications which would
register the stream callback and also in the libvirt daemons, when
modular daemons are used. The virStream remote driver client code is in
such deployments also used to tunnel requests from the hypervisor daemon
(virtqemud) to sub-daemons (virstoraged).
In those cases the leak is amplified as the stream event callback is
internally used to do the tunnelling and the daemon dispatch code stores
a reference to the 'virNetClient' object associated with the connection.
As this causes the last reference on the virNetClient object to be still
active, the corresponding connection to the storage daemon isn't closed
either, leaking a FD both in virtqemud and virtstoraged.
Internally the data is stored in 'struct remoteStreamCallbackData' which
is defined only in 'remote_driver.c' and there's no code which would
update the 'cb' field, thus the leak can't be avoided.
Remove the check for 'cb'. My assumption is that this was supposed to
mimic the 'dispatching' field in 'util/fdstream.c' or similar logic in
other dispatch functions.
The patch also adds debug statements which I've used to trace this.
The leak of a connection in 'virtqemud' has the following backtrace
under valgrind (note that the pointer is considered reachable and thus
this isn't visible in default config):
==3678343== 136 bytes in 1 blocks are still reachable in loss record 2,680 of 2,964
==3678343== at 0x48FC6CD: calloc (vg_replace_malloc.c:1616)
==3678343== by 0x4ED8A91: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8600.5)
==3678343== by 0x5019CA2: g_type_class_get (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x5001011: g_object_new_with_properties (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x5001EA0: g_object_new (in /usr/lib64/libgobject-2.0.so.0.8600.5)
==3678343== by 0x499E653: virObjectNew (virobject.c:252)
==3678343== by 0x499EA0F: virObjectLockableNew (virobject.c:274)
==3678343== by 0x4A84651: virNetClientStreamNew (virnetclientstream.c:144)
==3678343== by 0x4AE82AE: remoteStorageVolUpload (remote_client_bodies.h:8242)
==3678343== by 0x4BED13D: virStorageVolUpload (libvirt-storage.c:1809)
==3678343== by 0x4043539: remoteDispatchStorageVolUpload (remote_daemon_dispatch_stubs.h:20248)
==3678343== by 0x4043539: remoteDispatchStorageVolUploadHelper (remote_daemon_dispatch_stubs.h:20218)
==3678343== by 0x4A89A2C: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
==3678343== by 0x4A89A2C: virNetServerProgramDispatch (virnetserverprogram.c:299)
Resolves: https://redhat.atlassian.net/browse/RHEL-170773
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Simirarly to virAuthGetUsernamePath() check whether callback used
to collect credentials is actually set before calling it. This
bug is easily reproducible, for instance as:
int credtype[] = { VIR_CRED_PASSPHRASE };
virConnectPtr conn = virConnectOpenAuth("esx://root@example.com/",
&(virConnectAuth){
.credtype = credtype,
.ncredtype = 1,
.cb = NULL
},
0);
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The difference is that the usual UUID is supposed to be unique per host
and instanceUuid should be unique across the whole cluster. One could
think of them as HUID and CUID (as the first "U" does apparently mean
something else in the Broadcom world). That _would_ be fine for our
scenario. However, that piece of information turns out to be false as
well and the UUID we were using (`config.uuid`, or in VMX the
`uuid.bios`) can be the same in two machines on the same host.
Fortunately the `FindByUuid()` function can also search for VMs based on
their `instanceUuid`, dictated by the so far omitted third parameter.
Unfortunately that parameter is not parsed (or at least properly) before
vSphere API 4.0 (the documentation says 2.0, but we are not using that
namespace and 4.0 is the lowest we can target), which we are not
specifying in the server returns a 500 HTTP error if we use the
`instanceUuid` parameter.
So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
requests which makes that `FindByUuid()` function work even with the
`instanceUuid` set, but without any extra labor.
After that this patch also changes all UUIDs to be parsed from the
`config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
to the old `uuid.bios`) and adjusts tests accordingly.
To give users (and management applications) the possibility to revert
back to the previous (legacy) behaviour a new URI query parameter is
introduced, called `legacy_uuid` which, if set to `1`, still keeps the
code working as it did before this patch.
Last, but not least it changes the parameter to aforementioned function
to be true (unless the legacy behaviour is requested, of course) and
henceforth all searching ought to be done with the more unique ID.
Resolves: https://redhat.atlassian.net/browse/RHEL-174300
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Our bash completion script parses (partially incomplete) command
line and looks for two arguments: --readonly and --connect
because in the next step it executes virsh with those two
arguments like this:
virsh --readonly --connect $URI complete -- "text to complete"
Now, whenever virsh sees connection URI specified on its cmd line
it connects to it right away (before executing any command). This
happens inside virshConnect(). Here, virConnectOpenAuth() is
called with the default auth callback (virConnectAuthPtrDefault).
In majority of the cases this is desirable, as it might ask user
for credentials (password for example). But in case of bash
completion this is not desired because bash completion script
must not expect users to input anything (that's why we even
close stdin in cmdComplete()).
Therefore, when connecting from virsh that's executed by the bash
completion script provide no auth callbacks to prevent virsh from
asking for credentials.
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/879
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Richrad W.M. Jones <rjones@redhat.com>
The first thing that virNetLibsshAuthenticatePassword() does is
read password from config file. For this it does not need auth
callback. If that password fails to authenticate then
corresponding callback from the auth callback is called. This is
actual place where auth callback should be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Richrad W.M. Jones <rjones@redhat.com>
For the VIR_NET_SSH_AUTH_PASSWORD authentication mechanism the
virNetSSHAuthenticatePassword() is called. Inside it,
virAuthGetPasswordPath() is called to obtain password. Firstly
reading from our auth.conf file is attempted and if that fails
then corresponding callback from virConnectAuthCallbackPtr is
called. But virAuthGetPasswordPath() checks whether the callback
is NULL or not. There is no need for
virNetSSHAuthenticatePassword() to check it too. Drop the
duplicate check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Richrad W.M. Jones <rjones@redhat.com>
Implement QEMU Guest Agent support for bhyve. In bhyve it can configured
using the virtio-console device.
This change covers only two APIs using the agent:
- DomainQemuAgentCommand -- the most generic one.
- DomainGetHostname -- extended to support not only DHCP lease source,
but an agent as well.
It shares the qemu agent implementation with the qemu driver.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
To prepare for the qemu agent support for the bhyve driver,
move the implementation from qemu/ to hypervisor. This way
this implementation can be shared across multiple drivers.
The move is mostly mechanical except qemuAgentOpen()
which now accepts the "timeout" argument for the agent timeout.
As the original code used QEMU_DOMAIN_PRIVATE() to access
the agent timeout value, this change allows to make the code
driver-independent.
qemuAgentOpenUnix() is wrapped with #ifndef WIN32 so it does not fail on
mingw.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The new XML element is <energytune> under <cputune> following earlier pattern for
resctrl features (cachetune, memorytune). Energytune doesn't currently support
the "tuning" part, only monitoring. I added it as energytune for consistency with
cache and memory features, keeping all resctrl handling under cputune. This also makes
sense with current resctrl architecture - all monitoring groups are part of an
allocation group.
Changes:
- Added <energytune> parsing to domain_conf.c
- Added schema definition in domaincommon.rng
- Documented the element in formatdomain.rst
- Added energytune test
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com>
Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Expose PERF_PKG_MON energy monitoring capabilities in the host
capabilities XML.
<energy>
<monitor maxMonitors='576'>
<feature name='core_energy'/>
<feature name='activity'/>
</monitor>
</energy>
Changes:
- Add virCapabilitiesFormatEnergy() to emit <energy> XML block
- Add virCapabilitiesInitEnergy() to init from PERF_PKG_MON info
- Add <energy> element and energyMonitorFeature to capability.rng
- Update qemu_driver to support VIR_RESCTRL_MONITOR_TYPE_ENERGY
- Add virCapsHostEnergy struct
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com>
Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Linux 7.0 introduced in resctrl PERF_PKG_MON interface that exposes per-package
energy and performance counters. This patch extends virresctrl implementation
to discover and read energy counters from this new resource type.
(core_energy - Joules, activity - Farads)
Changes:
- Add Energy features allow-list virResctrlEnergyFeatures
since PERF_PKG_MON is not prefix-based.
- Added perf_monitor_info to _virResctrlInfo to contain _virResctrlInfo capabilities
- New virResctrlGetPerfMonitorInfo following earlier virResctrlGetMonitorInfo
to check new resource capabilities
- Added VIR_RESCTRL_MONITOR_TYPE_ENERGY and mapped it to energy allow-list
- Added dvals/ndvals pair to _virResctrlMonitorStats to support floating-point
counters and integer counters in single monitor (to support integer perf counters
in the future).
- Added floating-point read + parse in virResctrlMonitorGetStats for energy counters
- Stubbed VIR_RESCTRL_MONITOR_TYPE_ENERGY in qemu_driver
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com>
Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
On systems with many users, this file can be larger than BUFSIZ.
Since the file should only be editable by root and virFileReadAll
reallocates the buffer in increments as needed as opposed to
allocating for 'maxlen' upfront, set the maximum to INT_MAX.
https://gitlab.com/libvirt/libvirt/-/work_items/874
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This reverts commit 443c79dd7f.
Change from VIR_FREE() to g_free meant there is a possible double free
when there is an error during parsing because the parsing it done
directly into the parsedUri member of the esxPrivate, free'd when it
fails and then the caller calls free on it again. Changing back to
VIR_FREE() means there is no double free and no crash.
Reproducible easily with `virsh -c esx://l?no_verify=2`.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Use newly introduced testutils APIs to detect unused files.
This is pretty much straightforward, except for one small thing:
some test cases depend on QEMU (and are NOP if built without it).
Hence the condition in testCaseEnumerate().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are couple of files under tests/cputestdata/ that are not
used by any test case:
1) ppc64-guest-host-model.xml - unused since its introduction in
v1.2.19-rc1~31
2) ppc64-host+guest-host-model.xml - Same
3) x86_64-bogus-vendor.xml - Introduced in v0.8.7~195 under
slightly different name, then renamed to the current name (in
v3.1.0-rc1~3) but never used actually.
Just drop these three files.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use newly introduced testutils APIs to detect unused files.
This is pretty much straightforward except for one test case:
hostdev. This test case queries sysfs under the hood and thus is
expected to succeed on Linux and fail everywhere else. Though,
hostdev.expect.xml is thus used on Linux only. Therefore, do not
collect it on non-Linux platforms.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The passthrough-pf.conf file is not used really, because the test
case is defined as:
DO_TEST_VALIDATE_ERROR("passthrough-pf");
meaning the test is expected to fail in XML validation phase.
Hence, no .conf file is ever generated for it. Remove the file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuxmlconftest detects unused files in qemuxmlconfdata/
directory. But it uses its own implementation for that. But now
that there's a generic implementation available, switch to that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is basically a generalized version of what we have in
qemuxmlconftest (functions testConfXMLEnumerate(),
testQemuConfMarkUsed() and testConfXMLCheck()). The idea is to
reuse the code in other tests.
There's one slight difference to the original - while
qemuxmlconftest always allocated the hash table, in this
generalized version NULL table is okay.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For making introspection possible both qemuDomainSetSchedulerParameters
and qemuDomainSetSchedulerParametersFlags need to have the check
present.
Refactor the flag validation to make it present in both APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor the validation using 'virTypedParamsValidateTemplate' and
export the template so that 'qemuNodeSetMemoryParameters' can expose
them via introspection.
In addition since 'virHostMemSetParameters' is conditionally compiled,
platforms which don't support it will not expose given params.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor the code to use the new helper for validating migration params
and making them later available for introspection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'virTypedParamsValidate', which uses varargs to pass the template
to validate parameters against, is convenient for single uses we have
multiple occasions where we want to validate the same list of parameters
in muliple places. We use either a macro which expands to the parameter
list in place or a function which encapsulates the validation.
For introspection of input typed parameters we'll need to have the list
of supported typed parameters in each function which uses them as input
and either of the approaches is inconvenient for generating the
introspection parts.
Refactor 'virTypedParamsValidate', to split the actual validation
internals into ''virTypedParamsValidateInternal' and create two
wrappers:
- 'virTypedParamsValidate' which uses varargs
- 'virTypedParamsValidateTemplate' which uses an array of structs
containing the template.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The implementation uses 'virDomainObjGetMetadata'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The implementation uses 'virDomainQemuMonitorEventStateRegisterID'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The implementation uses 'qemuDomainQemuMonitorCommandWithFiles'
internally. To have a top level flag validation for the upcoming flag
introspection export the supported flags as a macro and add a
'virCheckFlags'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The implementation for managed save uses 'qemuDomainSaveImageDefineXML'
internally which validates the flags. To have a top level flag
validation for the upcoming flag introspection export the supported
flags as a macro and add a 'virCheckFlags' to
'qemuDomainManagedSaveDefineXML'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag check inside 'qemuDomainGetSEVInfo' makes no sense because it
only validates the 'VIR_TYPED_PARAM_STRING_OKAY' which is not actually
used.
Remove the 'flags parameter from 'qemuDomainGetSEVInfo' and validate
flags at 'qemuDomainGetLaunchSecurityInfo'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the 'virCheckFlags' invocations to the top level driver function so
that they become available for introspection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Create QEMU_DOMAIN_RESTORE_FLAGS define which collects all the flags
used by either of the implementations of the 'Restore' API and move the
flag checking into the implementation function so that it's available
later for introspection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the flag check to the top level to allow programatic introspection
of supported flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the flag check to the top level to allow programatic introspection
of supported flags.
Extract the supported flags as a macro so that they can be reused in
both coredump APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the flag check to the top level to allow programatic introspection
of supported flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the flag check to the top level to allow programatic introspection
of supported flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the unused argument and bump the 'virCheckFlags' calls to the top
level.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The utility functions which get memory stats don't actually use the
flags. Remove the argument and move the 'virCheckFlags' to driver
implementation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The utility functions which get CPU map and stats don't actually use the
flags. Remove the argument and move the 'virCheckFlags' to driver
implementation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Validate also variables exported as 'extern' e.g. from the util
submodule.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa
Michal Privoznik
Martin Kletzander
Roman Bogorodskiy
Jedrzej Wasiukiewicz
Ján Tomko