There were a number of occurrences where we used nested inline markup
(verbatim + refs) which is currently not possible with RST syntax [1].
There is a possible workaround involving substitution definitions like
.. |virConnectPtr| replace:: ``virConnectPtr``
.. _virConnectPtr: /html/libvirt-libvirt-host.html#virConnectPtr
Substitutions cannot be made generic, hence we cannot create a template
for substitution and use a single template everywhere, so we'd end up
with a lot of clutter and convolution. Therefore, we can make an
exception and just link the data type without further style markup.
[1] https://docutils.sourceforge.io/FAQ.html#is-nested-inline-markup-possible
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When switching to g_autoptr this was incorrectly changed from
'continue;' into 'return -1;' resulting into an error when user tries
to set vcpu_quota of running VM:
error: An error occurred, but the cause is unknown
Fixes: e4a8bbfaf2
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
In short, virXXXPtr type is going away. With big bang. And to
help us rewrite the code with a sed script, it's better if each
variable is declared on its own line.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The name is supposed to be virCapsGuestArchPtr not ..ptr.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The aim of virSecurity rule is to discourage from using plain
virSecurityManager*() APIs within QEMU driver in favor of their
qemuSecurity*() counterparts. The reason is simple: namespaces;
virSecurityManager*() needs additional
virSecurityManagerTransactionCommit() call to enter given
namespace and do its work from there. And that's exactly what
those qemuSecurity*() wrappers do.
To help us ensure correctness (from this POV), we have a
syntax-check rule that forbids any occurrence of
"virSecurityManager" string under src/qemu/ (except for
qemu_security of course).
But with if we want to remove virSecurityManagerPtr type, then we
have to allow "virSecurityManager *". Therefore, change the rule
so that no call of a function with "virSecurityManager" prefix is
allowed. And also change the name to better reflect what is going
on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The use of virXXXPtr is going away soon, therefore use 'virXXX *'
instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
What we are using really is heap allocated structure rather than
stack allocated. And for that it's better to use g_autoptr() +
G_DEFINE_AUTOPTR_CLEANUP_FUNC() combo, as Glib documentation for
g_auto() reads:
This is meant to be used with stack-allocated structures and
non-pointer types. For the (more commonly used) pointer
version, see g_autoptr().
This will be even more visible, when virSysinfoDefPtr type is
gone. Stay tuned.
Fixes: cee3a900a0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemu shim spawns a separate thread in which the event loop is
ran. The virEventRunDefaultImpl() call is wrapped in a while()
loop, just like it should. There are few lines of code around
which try to ensure that domain is destroyed (when quitting) and
that the last round of event loop is ran after the
virDomainDestroy() call. Only after that the loop is quit from
and the thread quits.
However, if domain creation fails, there is no @dom to call
destroy over, the @quit flag is never set and while() never
exits. Set the flag regardless of @dom pointer.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1920337
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The commandline generator for 'iothread' objects has a private
implementation of the properties. Convert it to JSON so that it can be
later validated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the 'sev0' sev-guest object will never be hotplugged, but we want
to generate it through JSON so that we'll be able to validate all
parameters of '-object' against the QAPI schema once 'object-add' is
qapified in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the 'masterKey0' secret object will never be hotplugged we want to
generate it through JSON so that we'll be able to validate all
parameters of '-object' against the QAPI schema once 'object-add' is
qapified in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 94e45d1042 broke exec-restart of virtlogd and virtlockd as the
code waiting for the daemon shutdown closed the daemons before
exec-restarting.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1912243
Fixes: 94e45d1042
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Recent changes which meant to fix daemon shutdown broke the exec-restart
capability of virtlogd and virtlockd, since the code actually closed all
the sockets and shut down all the internals.
Add virNetDaemonQuitExecRestart, which requests a shutdown of the
process, but keeps all the services open and registered since they are
preserved across the restart.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This problem is reproducible only with secret driver. When
starting a domain via virt-qemu-run and both secret and
(nonexistent) root directory specified this is what happens:
1) virt-qemu-run opens "secret:///embed?root=$rootdir"
connection, which results in the secret driver initialization
(done in secretStateInitialize()). During this process, the
driver creates its own configDir (derived from $rootdir)
including those parents which don't exists yet. This is all
done with the mode S_IRWXU and thus results in the $rootdir
being created with very restrictive mode (specifically, +x is
missing for group and others).
2) now, virt-qemu-run opens "qemu:///embed?root=$rootdir" and
calls virDomainCreateXML(). This results in the master-key.aes
being written somewhere under the $rootdir and telling qemu
where to find it.
But because the secret driver created $rootdir with too
restrictive mode, qemu can't access the file (even though it
knows the full path) and fails to start.
It looks like the best solution is to pre-create the root
directory before opening any connection (letting any driver
initialize itself) and set its mode to something less
restrictive.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1859873
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In theory, users might want to use a relative path as a root
directory for embed drivers. But in practice, nothing in driver
initialization (specifically QEMU driver since it's the only one
that supports embedding now), is prepared for that. Document and
enforce absolute paths.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1883725
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since v6.2.0-rc1~238 (and friends) QMP processing was moved to a
per-domain thread. Therefore, it is now safe to call APIs from
the event loop thread (e.g. just like qemu shim is doing in
qemuShimEventLoop(). However, it is still important to let the
event loop run after each API call (obviously).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
'res->owners' is allocated to 'res->nOwners' elements, but unfortunately
'res->nOwners' doesn't contain the proper value until after the
allocation so 0 elements are allocated. The following loop which assumes
that the array has the right number of elements then accesses the
pointer out of bounds. The bug was also faithfully converted from
VIR_ALLOC_N to g_new0.
Fixes: 4a3d6ed5ee
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Recent refactor marked 'object' which is returned from the function as
autofree but forgot to use g_steal_pointer in the return statement to
prevent freeing it.
Fixes: 9a1651f64d
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit cb29e4e801 didn't take into account that the VM can be inactive
when it's destroyed. This means that the job would remain active also
when the VM became inactive.
To fix this properly:
1) Remove the bogus VM liveness check and early return
(reverts the aforementioned commit)
2) Conditionalize the stats assignment only when the stats object is
present
(properly fix the crash when VM dies when reconnecting)
3) end the asyncjob only when it was already set
(prevent corruption of priv->jobs_queued)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1937598
Fixes: cb29e4e801
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemuBackupJobTerminate' needs the API flags to see whether
VIR_DOMAIN_BACKUP_BEGIN_REUSE_EXTERNAL. Unfortunately when called via
qemuProcessReconnect()->qemuProcessStop() early (e.g. if the qemu
process died while we were reconnecting) the job is cleared temporarily
so that other APIs can be called. This would mean that we couldn't clean
up the files in some cases.
Save the 'apiFlags' inside the backup object and set it from the
'qemuDomainJobObj' 'apiFlags' member when reconnecting to a VM.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There was a bug in the code adding TasksMax property. It remained
undetected because all tests used '0' for @maxthreads.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
g_variant_new_parsed uses '%t' for a uint64_t rather than printf-like
%llu. Additionally ensure that the passed value is a uint64_t since the
argument used is a 'unsigned int'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1937287
Fixes: bf5f2ed09c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function is now unused and motivated users to write crazy parsers
which were hard to understand, had pointless error paths just to avoid
few memory allocations.
Remove the function as we're fine with g_strndup and virStrcpy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use g_strsplit to split the string and avoid use of stack'd strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is similar to my earlier commit which documented lxc.conf
location. Just like LXC, the libxl driver has only the system
connection and thus only few places need changing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The libxl driver has no session daemon therefore its split daemon
(virtxend) has to be ran as root. Any attempt to start it with
euid != 0 fails. This is why the daemon does not look under any
of XDG_* paths either.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This is similar to my earlier commit which documented qemu.conf
locations. Luckily, the LXC driver has only the system connection
and not session or embed one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The LXC driver has no session daemon therefore its split daemon
(virtlxcd) has to be ran as root. Any attempt to start it with
euid != 0 fails. This is why the daemon does not look under any
of XDG_* paths either.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In official docs we refer to it as "QEMU driver", not "qemu
driver".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
make is only used for the syntax-check tests, which we are
explicitly skipping when building RPMs.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only place where gethostname() is acceptable is in
virGetHostnameImpl() which lives in src/util/virutil.c.
Reflect this in the list of exceptions for the syntax-check rule.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The problem is that g_get_host_name() caches the hostname in a
thread local variable. Therefore, it doesn't reflect any
subsequent hostname changes. While this might be acceptable for
logs where the hostname is printed exactly once when the libvirtd
starts up, it is not optimal for virGetHostnameImpl() which is
what our public virConnectGetHostname() API calls. If the
hostname at the moment of the first API invocation happens to
start with "localhost" or contains a dot, then no further
hostname changes will ever be reflected.
This reverts 26d9748ff1, partially.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already assume that 'retr_passphrase.result' is a string, thus we can
use virStrcpy instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use g_strndup with a freed buffer instead of the more complex approach
using virStrncpy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make the temporary string an autofree-ing pointer and copy the contents.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rewrite so that the parser doesn't use virStrncpy by employing
g_strsplit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Copy the input string so that we don't have to use a static buffer and
virStrncpy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, validation of XML failed if sub-elements of video
device were in different order.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1825769
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
With this, XML fails if config video type 'ramfb' contains
address, since address is not supported for 'ramfb' video
devices. Previously it didn't raise error.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1891416
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Switch to using the 'g_auto*' helpers.
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This introduces support for the QEMU audio settings that are common to
all audio backends. These are expressed in the QAPI schema as settings
common to all backends, but in reality some backends ignore some of
them. For example, some backends are output only. The parser isn't
attempting to apply restrictions that QEMU itself doesn't apply.
<audio id='1' type='pulseaudio'>
<input mixingEngine='yes' fixedSettings='yes' voices='1' bufferLength='100'>
<settings frequency='44100' channels='2' format='s16'/>
</input>
<output mixingEngine='yes' fixedSettings='yes' voices='2' bufferLength='100'>
<settings frequency='22050' channels='4' format='f32'/>
</output>
</audio>
The <settings> child is only valid if fixedSettings='yes'
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The -audiodev argument is replacing the QEMU_AUDIO_DRV env variable (and
its relations).
Sadly we still have to use the SDL_AUDIODRIVER env variable because that
wasn't mapped into QAPI schema.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The -audiodev arg is a new way to configure audio devices in QEMU to
replace the QEMU_AUDIO_DRV env variable. This arg is not visible in
the "query-command-line-options" output since it is entirely QAPI
driven, not QemuOpts. It also isn't in "query-qmp-schema" though
since there's no QMP command that uses the Audiodev type yet.
So probe for the existance of this feature by looking for the
-vnc "audiodev" property. This won't let us determine which
precise audio backends QEMU has been built with, but for now
that's no worse than with env variables today.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
