The features are reported in a 0x1 subleaf of 0x1e CPUID leaf.
QEMU commit 956b8f0fc38a5ead18d9bf5ceba0861627738835 (some feature were
later renamed by 85dc6147e79140f17b7e4333ec14f302bf9b5e97, which
happened in the same QEMU release so we don't need to care about the
original names).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU defines some CPU models with hexadecimal family, but our CPU map
loading code expects decimals.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
children variable is a list returned by getchildren().
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When QEMU driver emits agent connected/disconnected events (inside of
processSerialChangedEvent()) it declares a variable of
virDomainChrDeviceState enum, and then passes this variable to
virDomainEventAgentLifecycleNewFromObj(). But we document the agent
lifecycle state to be of virConnectDomainEventAgentLifecycleState enum.
Therefore, make sure values from
virConnectDomainEventAgentLifecycleState enum are of the same value as
those in virDomainChrDeviceState enum.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When virNetDevBandwidthSet is called for a macvtap device in
qemu_command and qemu_hotplug, qemuDomainInterfaceSetDefaultQDisc has
been called already, setting the iface qdisc to 'noqueue'. If the
interface has an inbound-only bandwidth limit, the outgoing qdisc
on the device will be reset to the system default.
<interface type="direct">
...
<bandwidth>
<inbound average='3125000' peak='3125000'/>
</bandwidth>
</interface>
This only clears the qdisc on an interface before a bandwidth limit is
actually set.
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/875
Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This allows virNetDevBandwidthSet to clear only the interface's qdisc
for directions where bandwidth is defined (see the next patch)
Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are 2 bugs in virTypedParamsValidateTemplate's counting of the
passed amount of templates:
- the condition looked for empty strings rather than non-empty ones
- the count was 1 more than the amount of templates due to use of
post-increment directly in the condition
Fixes: 4561735158
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/880
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
virObject internally uses g_object which doesn't expose the internal
reference count. When debug logging we log ref/unref operations but when
reading logs it's hard to follow if a precise reference count is needed
at some points.
Add a private reference counter variable and use it in debug messages of
virObject operations.
The code is designed so that it can be disabled if ever needed since
it's just for debugging. For now let's keep it enabled.
With all the informaton added the logs look like (timestamps trimmed):
debug : virObjectRef:424 : OBJECT_REF: obj=0x7fffac001d30 classname=qemuMonitor refs=3
debug : virObjectUnref:392 : OBJECT_UNREF: obj=0x7fffac001d30 classname=qemuMonitor refs=2
debug : virObjectNew:264 : OBJECT_NEW: obj=0x7fffac00db70 classname=virDomainEventAgentLifecycle
debug : virObjectUnref:392 : OBJECT_UNREF: obj=0x7fffac00db70 classname=virDomainEventAgentLifecycle refs=0
debug : vir_object_finalize:328 : OBJECT_DISPOSE: obj=0x7fffac00db70 classname=virDomainEventAgentLifecycle
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
Jiri Denemark
Michal Privoznik
Jonathan Davies
Wesley Hershberger via Devel
Peter Krempa
Martin Kletzander
Roman Bogorodskiy
Jedrzej Wasiukiewicz
Ján Tomko