Instead of creating an empty object and then setting keys one
at a time, it is possible to pass a dict object to
configuration_data(). This is nicer because it doesn't require
repeating the name of the cfg_data object over and over.
There is one exception: the 'conf' object, where we store values
that are used directly by C code. In that case, using a dict
object is not feasible for two reasons: first of all, replacing
the set_quoted() calls would result in awkward code with a lot
of calls to format(); moreover, since code that modifies it is
sprinkled all over the place, refactoring it would probably
make things more complicated rather than simpler.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Switch the operands in the loop condition to make it converge.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This API has the same semantics as 'virDomainQemuMonitorCommand' but
accepts file descriptors which are then forwarded to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The systemd version in RHEL-7 lacked support for the LISTEN_FDNAMES env
variable with socket activation. Since we stopped targetting RHEL-7 we
can drop some considerable amount of compatibility code.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Adding an exception for the whole file usually defeats the purpose of a
syntax check and is also likely to get forgotten once the file is
removed.
In case of the suggestion of using 'safewrite' instead of write even the
comment for safewrite states that the function needs to be used only in
certain cases.
Remove the blanket exceptions for files and use an exclude string
instead. The only instance where we keep the full file exception is for
src/libvirt-stream.c as there are multiple uses in example code in
comments where I couldn't find a nicer targetted wapproach.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change was generated using the following spatch:
@ rule1 @
expression a;
identifier f;
@@
<...
- f(*a);
... when != a;
- *a = NULL;
+ g_clear_pointer(a, f);
...>
@ rule2 @
expression a;
identifier f;
@@
<...
- f(a);
... when != a;
- a = NULL;
+ g_clear_pointer(&a, f);
...>
Then, I left some of the changes out, like tools/nss/ (which
doesn't link with glib) and put back a comment in
qemuBlockJobProcessEventCompletedActiveCommit() which coccinelle
decided to remove (I have no idea why).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We recently started listing these in the spec file and, since we
were not creating them during the installation phase, that broke
RPM builds.
Fixes: 4b43da0bff9b78dcf1189388d4c89e524238b41d
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The service files were copied out of the service file for libvirtd and
the name of the corresponding manpage was not fixed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2045959
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The existence of the unix socket path is used by the remote driver to
determine whether modular daemons are in use, so if the socket file
stays behind and the user decided to switch from modular to monolithic
daemon which was socket activated, the remote driver will insist on
picking '/var/run/libvirt/virtqemud-sock', even when it's no longer in
use:
# systemctl start libvirtd.service
# virsh list
Id Name State
--------------------
# systemctl stop libvirtd.service
Warning: Stopping libvirtd.service, but it can still be activated by:
libvirtd.socket
libvirtd-ro.socket
libvirtd-admin.socket
# systemctl start virtqemud.socket
# virsh list
Id Name State
--------------------
# systemctl stop virtqemud.socket
# systemctl start libvirtd.service
# virsh list
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': Connection refused
# virsh -c 'qemu:///system?socket=/var/run/libvirt/libvirt-sock' list
Id Name State
--------------------
Fix this by instructing systemd to delete the socket file when
deactivating the unit file for the socket.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
sysconfig files are owned by the admin of the host. They have the
liberty to put anything they want into these files. This makes it
difficult to provide different built-in defaults.
Remove the sysconfig file and place the current desired default into
the service file.
Local customizations can now go either into /etc/sysconfig/name
or /etc/systemd/system/name.service.d/my-knobs.conf
Attempt to handle upgrades in libvirt.spec.
Dirty files which are marked as %config will be renamed to file.rpmsave.
To restore them automatically, move stale .rpmsave files away, and
catch any new rpmsave files in %posttrans.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There is no need to do that since both fallible functions do that already.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
And make callers check the return value as well. This helps error out early for
invalid environment variables.
That is desirable because it could lead to deadlocks. This can happen when
resetting logging after fork() reports translated errors because gettext
functions are not reentrant. Well, it is not limited to resetting logging after
fork(), it can be any translation at that phase, but parsing environment
variables is easy to make fail on purpose to show the result, it can also happen
just due to a typo.
Before this commit it is possible to deadlock the daemon on startup
with something like:
LIBVIRT_LOG_FILTERS='1:*' LIBVIRT_LOG_OUTPUTS=1:stdout libvirtd
where filters are used to enable more logging and hence make the race less rare
and outputs are set to invalid
Combined with the previous patches this changes
the following from:
...
<deadlock>
to:
...
libvirtd: initialisation failed
The error message is improved in future commits and is also possible thanks to
this patch.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This prevents starting any daemons with improper logging settings. This is
desirable on its own, but will be even more beneficial when more functions start
reporting errors and failing on them, coming up in following patches
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When using the monolithic daemon the driver for virStream is
always virFDStreamDrv and thus calling virStreamInData() results
in calling virFDStreamInData().
But things are different with split daemon, especially when a
client connects to one of hypervisor daemons (e.g. virtqemud) and
then lets the daemon connect to the storage daemon for
vol-upload/vol-download. Here, the hypervisor daemon acts like
both client and server. This is reflected by stream->driver
pointing to remoteStreamDrv, which doesn't have streamInData
callback implemented and thus vol-upload/vol-download with sparse
flag fails.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026537
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
So far, virStreamInData() is effectively a wrapper over
virFDStreamInData() which means it deals with files which can be
rewound (lseek()-ed) to whatever position we need. And in fact,
that's what virFDStreamInData() does - it makes sure that the FD
is left unchanged in terms of position in the file. Skipping the
hole happens soon after - in daemonStreamHandleRead() when
virStreamSendHole() is called.
But this is about to change. Soon we will have another implementation
where we won't be dealing with FDs but virNetMessage queue and it will
be handy to pop message at the beginning of the queue. Implement and
document this new behavior.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Specifically:
* include non-option argument 'URI' in usage summary;
* mention that it's an internal tool not meant to be
called directly;
* exit earlier if required arguments are absent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's a getopt interface and we're not using getopt, at least
directly, so even though it works relying on it feels wrong.
GOption takes care of removing any trace of the arguments it
consumes from argc and argv, leaving behind only non-option
arguments, so we can just use those standard variables.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to make sure the URI scheme is present before passing
it to strchr(), otherwise we're going to get
$ virt-ssh-helper foo
Segmentation fault (core dumped)
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The initialization of drivers happens in a separate thread.
However, the main thread continues initialization and sets
shutdown callbacks (virStateShutdownPrepare() and
virStateShutdownWait()) even though the driver init thread is
still running. This is dangerous because if the daemon decides to
quit early (e.g. because SIGINT was delivered) the
shutdownPrepare and shutdownWait callback are called over
partially init drivers.
Set callbacks only after all drivers were initialized.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/218
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2027400
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
To make it easier for users to figure out how the DN should be formatted.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This removes a dead link, the need for users to understand a glib function and a
improper reference to fnmatch (as we only expand asterisks to any string).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are a few cases where a string list is freed by an explicit
call of g_strfreev(), but the same result can be achieved by
g_atuo(GStrv).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
If there is no tcp_min_ssf value set in daemon config we still
compare it against the default (56 which corresponds to DES) and
if the value is below our expected minimum (112 which corresponds
to 3DES) an error is reported and the daemon refuses to start.
This is not what we want. What we want is to check the value iff
the value was specified in the config file.
Fixes: 58a48cff840
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an option to allow the admin to requet a higher minimum SSF
for connections than the built-in default.
The current default is 56 (single DES equivalent, to support
old kerberos) and will be raised to 112 in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=1431589
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Store the minimum SSF value for TCP connections
in virNetSASLContext and introduce a getter for it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Prepare for deprecating old kerberos ciphers by warning users
with a SSF lower than 112.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.
This current size is reported in the domain XML as an output
element only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This new API creates network with given flags.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These two public APIs are implemented for almost all other objects that
have a concept of persistent definition and activatability. Now that we
have node devices (mdevs) that can be defined and inactive, it will be
useful to query the persistent/active state of node devices as well.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will allow persistent mediated devices to be configured to be
restarted automatically when the host reboots.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This new API allows to define network with given flags.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new API function allows to define nwfilter with given flags.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Both virDomainAuthorizedSSHKeysGet and virDomainGetMessages return a
NULL-terminated string-list, so we can use g_auto(GStrv) to clear the
used memory on failures.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit 05bd8db60b35b7706100d9cbbaeb13992965e0f2.
It is true that the remote driver client now contains logic for probing
the driver to connect to when using modular daemons. This logic, however,
only runs when the remote driver is NOT running inside a daemon since we
don't want it activated inside libvirtd. Since the same remote driver
build is used in all daemons, we can't rely on it in virtproxyd either.
Thus we need to keep the virtproxyd probing logic
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use virAppendElement instead of virInsertElementsN to implement
VIR_APPEND_ELEMENT which allows us to remove error handling as the
only relevant errors were removed when switching to aborting memory
allocation functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the remote driver itself can probe for listening sockets /
running daemons, virtproxyd doesn't need to probe URIs itself. Instead
it can just delegate to the remote driver.
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With the traditional libvirtd, the virConnectOpen call will probe active
drivers server side to find which one to use when the URI is NULL/empty.
With the modular daemons though, the remote client does not know which
daemon to connect in the first place, so we can't rely on virConnectOpen
probing. Currently the virtproxyd daemon has code to probe for a
possible driver by looking at which sockets are listening or which
binaries are installed. The remote client can thus connect to virtproxyd
which in turn can connect to a real hypervisor driver.
The virtproxyd probing code though isn't something that needs to live in
virtproxyd. By moving it into the remote client we can get probing
client side in all scenarios and avoid the extra trip via virtproxyd in
the common case.
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When virtproxyd gets a NULL URI, it needs to implement probing logic
similar to that found in virConnectOpen. The latter can't be used
directly since it relied on directly calling into the internal drivers
in libvirtd. virtproxyd approximates this behaviour by looking to see
what modular daemon sockets exist, or what daemon binaries are installed.
This same logic is also going to be needed when the regular libvirt
remote client switches to prefer modular daemons by default, as we
don't want to continue spawning libvirtd going forward.
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libxl driver supports xen:///system URLs and the daemon socket
uses 'virtxend' as the socket prefix.
Reported-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In fcdcf8f70cf the remoteGetUNIXSocket() function was changed and
one new variable was introduced (among other things): @env_name.
However, for WIN32 case the variable changed name to @env_path
which builds mingw builds.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When the default driver mode requests the modular daemons, we still
defaulted to spawning libvirtd if the URI was NULL, because we don't
know which driver specific daemon to spawn. virtproxyd has logic
that can handle this as it is used for compatibility when accepting
incoming TCP connections with a NULL URI.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The "spawnDaemon" and "binary" parameters are co-dependant, with the
latter non-NULL, if-and-only-if the former is true. Getting rid of the
"spawnDaemon" parameter simplifies life for the callers and eliminates
an error checking scenario.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
