remote: handle autoprobing of driver within virtproxyd
The virtproxyd daemon is merely responsible for forwarding RPC calls to
one of the other per-driver daemons. As such, it does not have any
drivers loaded and so regular auto-probing logic will not work. We need
it to be able to handle NULL URIs though, so must implement some kind of
alternative probing logic.
When running as root this is quite crude. If a per-driver daemon is
running, its UNIX socket will exist and we can assume it will accept
connections. If the per-driver daemon is not running, but socket
autostart is enabled, we again just assume it will accept connections.
The is not great, however, because a default install may well have
all sockets available for activation. IOW, the virtxend socket may
exist, despite the fact that the libxl driver will not actually work.
When running as non-root this is slightly easier as we only have two
drivers, QEMU and VirtualBox. These daemons will likely not be running
and socket activation won't be used either, as libvirt spawns the
daemon on demand. So we just check whether the daemon actually is
installed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: open secondary drivers via remote driver if needed
When the client has a connection to one of the hypervisor specific
daemons (eg virtqemud), the app may still expect to use the secondary
driver APIs (storage, network, etc). None of these will be registered in
the hypervisor daemon, so we must explicitly open a connection to each
of the daemons for the secondary drivers we need.
We don't want to open these secondary driver connections at the same
time as the primary connection is opened though. That would mean that
establishing a connection to virtqemud would immediately trigger
activation of virtnetworkd, virnwfilterd, etc despite that that these
drivers may never be used by the app.
Thus we only open the secondary driver connections at time of first use
by an API call.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: change hand written methods to not directly access connection
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: fix lock ordering mistake in event registration
If the event (un)registration methods are invoked while no connection is
open, they jump to a cleanup block which unlocks a mutex which is not
currently locked.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: change generated methods to not directly access connection
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
admin: add ability to connect to the per-driver daemon sockets
The admin client now supports addressing the per-driver daemons using
the obvious URI schemes for each daemon. eg virtqemud:///system
virtqemud:///session, etc.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvzd daemon will be responsible for providing the vz API
driver functionality. The vz driver is still loaded by the main
libvirtd daemon at this stage, so virtvzd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtbhyved daemon will be responsible for providing the bhyve API
driver functionality. The bhyve driver is still loaded by the main
libvirtd daemon at this stage, so virtbhyved must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvboxd daemon will be responsible for providing the vbox API
driver functionality. The vbox driver is still loaded by the main
libvirtd daemon at this stage, so virtvboxd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtlxcd daemon will be responsible for providing the lxc API
driver functionality. The lxc driver is still loaded by the main
libvirtd daemon at this stage, so virtlxcd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtqemud daemon will be responsible for providing the qemu API
driver functionality. The qemu driver is still loaded by the main
libvirtd daemon at this stage, so virtqemud must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtxend daemon will be responsible for providing the libxl API
driver functionality. The libxl driver is still loaded by the main
libvirtd daemon at this stage, so virtxend must not be running at
the same time.
This naming is slightly different than other drivers. With the libxl
driver, the user still has a 'xen:///system' URI, and we provide it
in a libvirt-daemon-xen RPM, which pulls in a
libvirt-daemon-driver-libxl RPM.
Arguably we could rename the libxl driver to "xen" since it is the
only xen driver we have these days, and that matches how we expose it
to users in the URI naming.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnwfilterd daemon will be responsible for providing the nwfilter API
driver functionality. The nwfilter driver is still loaded by the main
libvirtd daemon at this stage, so virtnwfilterd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnodedevd daemon will be responsible for providing the nodedev API
driver functionality. The nodedev driver is still loaded by the main
libvirtd daemon at this stage, so virtnodedevd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtstoraged daemon will be responsible for providing the storage API
driver functionality. The storage driver is still loaded by the main
libvirtd daemon at this stage, so virtstoraged must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtinterfaced daemon will be responsible for providing the interface API
driver functionality. The interface driver is still loaded by the main
libvirtd daemon at this stage, so virtinterfaced must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnetworkd daemon will be responsible for providing the network API
driver functionality. The network driver is still loaded by the main
libvirtd daemon at this stage, so virtnetworkd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: introduce virtproxyd daemon to handle IP connectivity
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.
In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.
We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.
It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.
Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.
Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).
We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages
- We can make virtproxyd and the virtXXXd per-driver daemons all
have "Conflicts: libvirtd.service" in their systemd unit files.
This will guarantee that libvirtd is never started at the same
time, as this would result in two daemons running the same driver.
Fortunately drivers use locking to protect themselves, but it is
better to avoid starting a daemon we know will conflict.
- It allows us to break CLI compat to remove the --listen parameter.
Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
will default to zero. Either TLS or TCP can be enabled exclusively
though virtd.conf without requiring the extra step of adding --listen.
- It allows us to set a strict SELinux policy over virtproxyd. For
back compat the libvirtd policy must continue to allow all drivers
to run. We can't easily give a second policy to libvirtd which
locks it down. By introducing a new virtproxyd we can set a strict
policy for that daemon only.
- It gets rid of the weird naming of having a daemon with "lib" in
its name. Now all normal daemons libvirt ships will have "virt"
as their prefix not "libvirt".
- Distros can more easily choose their upgrade path. They can
ship both sets of daemons in their packages, and choose to
either enable libvirtd, or enable the per-driver daemons and
virtproxyd out of the box. Users can easily override this if
desired by just tweaking which systemd units are active.
After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.
The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.
The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.
The aggressive option is to disable libvirtd if already running
and activate all the new daemons.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: in per-driver daemons ensure that state initialize succeeds
When running in libvirtd, we are happy for any of the drivers to simply
skip their initialization in virStateInitialize, as other drivers are
still potentially useful.
When running in per-driver daemons though, we want the daemon to abort
startup if the driver cannot initialize itself, as the daemon will be
useless without it.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: refactor how list of systemd unit files is built
The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
.in suffix.
This won't work in future when a single .in unit file can be used to
generate multiple different units.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd socket unit files with other daemons by
making various parts of their config conditionally defined by the make
rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: reduce duplication in systemd unit file make rules into one
The make rules for the systemd socket unit files are all essentially
identical and can be collapsed into a single generic rule. The service
unit file rule can be simplified too.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
build: don't hardcode /etc in the config related files
Substitute in the @sysconfigdir@ value instead of /etc.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: refactor & rename variables for building libvirtd
The same make variables will be useful for building both libvirtd and
the split daemons, so refactor & rename variables to facilitate reuse.
Automake gets annoyed if you define a variable ending LDFLAGS:
src/remote/Makefile.inc.am:53: warning: variable 'REMOTE_DAEMON_LDFLAGS' is defined but no program or
src/remote/Makefile.inc.am:53: library has 'REMOTE_DAEMON' as canonical name (possible typo)
So we trick it by using an LD_FLAGS or LD_ADD suffix instead.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: conditionalize IP socket config in augeas definitions
Prepare for reusing libvirtd augeas defintions with other daemons by
making the config parameters for IP sockets conditionally defined by
the make rules.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: conditionalize IP socket config in libvirtd.conf
Prepare for reusing libvirtd config to create other daemons by making
the config parameters for IP sockets conditionally defined by the make
rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: conditionalize IP socket usage in libvirtd daemon
Prepare for reusing libvirtd source to create other daemons by making
the use of IP sockets conditionally defined by the make rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: conditionalize driver loading in libvirtd daemon
Prepare for reusing libvirtd source to create other daemons by making
the driver(s) to load conditionally defined by the make rules.
If nothing is set, all drivers will be loaded, ignoring any missing ones
as historically done.
If MODULE_NAME is set only one driver will be loaded and that one must
succeed.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: conditionalize daemon name in libvirtd daemon
Prepare for reusing libvirtd source to create other daemons by making
the daemon name conditionally defined by the make rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: stop trying to print help as giant blocks of text
The remote daemon tries to print out its help text in a couple of giant
blocks of text. This has already lead to duplication of the text for the
privileged vs unprivileged execution mode. With the introduction of more
daemons, this text is going to be duplicated many more times with small
variations. This is very unfriendly to translators as they have to
translate approximately the same text many times with small tweaks.
Splitting the text up into individual strings to print means that each
piece will only need translating once. It also gets rid of all the
layout information from the translated strings, so avoids the problem of
translators breaking formatting by mistake.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The augeas-gentest.pl program merges a config file into a augeas
file, saving the output to a new file. It is going to be useful
to further process the output file, and it would be easier if this can
be done with a pipeline, so change augeas-gentest.pl to write to stdout
instead of a file.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Jiri Denemark [Thu, 8 Aug 2019 13:36:00 +0000 (15:36 +0200)]
qemu: Pass correct qemuCaps to virDomainDeviceDefPostParse
Since qemuDomainDeviceDefPostParse callback requires qemuCaps, we need
to make sure it gets the capabilities stored in the domain's private
data if the domain is running. Passing NULL may cause QEMU capabilities
probing to be triggered in case QEMU binary changed in the meantime.
When this happens while a running domain object is locked, QMP event
delivered to the domain before QEMU capabilities probing finishes will
deadlock the event loop.
QEMU capabilities lookup (via domainPostParseDataAlloc callback) is
hidden inside virDomainDeviceDefPostParseOne with no way to pass
qemuCaps to virDomainDeviceDef* functions. This patch fixes all
remaining paths leading to virDomainDeviceDefPostParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Tue, 6 Aug 2019 12:19:35 +0000 (14:19 +0200)]
qemu: Pass correct qemuCaps to virDomainDefParseNode
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
Several general snapshot and checkpoint APIs were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefParseNode.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Tue, 6 Aug 2019 11:53:11 +0000 (13:53 +0200)]
qemu: Pass correct qemuCaps to virDomainDefPostParse
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to virDomainDefPostParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Tue, 6 Aug 2019 11:41:42 +0000 (13:41 +0200)]
qemu: Pass correct qemuCaps to virDomainDefCopy
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
Several general functions from domain_conf.c were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefCopy to do the
right thing.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Tue, 6 Aug 2019 10:31:45 +0000 (12:31 +0200)]
qemu: Pass qemuCaps to qemuMigrationCookieXMLParse
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuMigrationCookieXMLParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 5 Aug 2019 14:26:29 +0000 (16:26 +0200)]
qemu: Pass correct qemuCaps to virDomainDefParseString
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to virDomainDefParseString.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 5 Aug 2019 15:31:10 +0000 (17:31 +0200)]
qemu: Pass qemuCaps to qemuMigrationAnyPrepareDef
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuMigrationAnyPrepareDef.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 5 Aug 2019 14:40:19 +0000 (16:40 +0200)]
qemu: Pass qemuCaps to qemuDomainSaveImageOpen
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainSaveImageOpen.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Mon, 5 Aug 2019 14:05:20 +0000 (16:05 +0200)]
qemu: Pass qemuCaps to qemuDomainDefFormatBufInternal
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainDefFormatBufInternal.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Fri, 2 Aug 2019 15:36:56 +0000 (17:36 +0200)]
qemu: Pass qemuCaps to qemuDomainDefCopy
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainDefCopy.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If yajl_parse() fails, we try to print an error message. For
that, yajl_get_error() is used. However, its documentation say
that caller is also responsible for freeing the memory it
allocates by using yajl_free_error().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
nss: Include stdio.h and define NULLSTR when debugging is enabled
The NSS module has a compile time option which when enabled makes
ERROR() and DEBUG() print messages onto stderr. But now that the
module no longer links with libvirt, we need to include stdio.h
and define NULLSTR().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Due to latest rewrite of NSS module, we are doing yajl parsing
ourselves. This means, we had to introduce couple of callback
that yajl calls. According to its documentation, a callback can
cancel parsing if it returns a zero value. Well, we do just that
in the string callback (findLeasesParserString()). If the JSON
file we are parsing contains a key that we are not interested in,
zero is returned meaning stop all parsing. This is not correct,
because the JSON file can contain some other keys which are not
harmful for our address translation (e.g. 'client-id').
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
host-passthrough documentation menions that the source and destination
hosts are not identical in both hardware and configuration. Configuration
actually includes microcode version and QEMU version, but this is not
clear so make it explicit
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190802125415.15227-1-pbonzini@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
tools: Separate checkpoint related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
host (e.g. they complete various checkpoint aspects)
into virsh-completer-checkpoint.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sun, 14 Jul 2019 10:24:38 +0000 (12:24 +0200)]
tools: Separate host related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
host (e.g. they complete various host aspects)
into virsh-completer-host.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 17:24:01 +0000 (19:24 +0200)]
tools: Separate snapshot related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
snapshot (e.g. they complete various snapshot aspects)
into virsh-completer-snapshot.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 17:17:42 +0000 (19:17 +0200)]
tools: Separate secret related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
secret (e.g. they complete various secret aspects)
into virsh-completer-secret.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 17:02:24 +0000 (19:02 +0200)]
tools: Separate nwfilter related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
nwfilter (e.g. they complete various nwfilter aspects)
into virsh-completer-nwfilter.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:57:17 +0000 (18:57 +0200)]
tools: Separate nodedev related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
nodedev (e.g. they complete various nodedev aspects)
into virsh-completer-nodedev.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:51:56 +0000 (18:51 +0200)]
tools: Separate network related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
networks (e.g. they complete various network aspects)
into virsh-completer-network.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:45:48 +0000 (18:45 +0200)]
tools: Separate interface related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
interfaces (e.g. they complete various interface aspects)
into virsh-completer-interface.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:36:26 +0000 (18:36 +0200)]
tools: Separate storage volume related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
storage volumes (e.g. they complete various storage volume
aspects) into virsh-completer-volume.c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:27:12 +0000 (18:27 +0200)]
tools: Separate storage pool related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
storage pools (e.g. they complete various storage pool aspects)
into virsh-completer-pool.c.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Sat, 13 Jul 2019 16:00:35 +0000 (18:00 +0200)]
tools: Separate domain related completers into a file
Mixing all completers in one file does not support
maintainability. Separate those completers which relate to
domains (e.g. they complete various domain aspects) into
virsh-completer-domain.c.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Thu, 18 Jul 2019 15:18:28 +0000 (17:18 +0200)]
tools: Expose virshCommaStringListComplete()
In next commits the virsh-completer.c is going to be split into
smaller files. Expose virshCommaStringListComplete() so that it
can still be used from those new files.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Roman Bolshakov [Thu, 8 Aug 2019 10:37:46 +0000 (13:37 +0300)]
tests: Fix message for IP parse/format failures
Confusing message is printed when a parse/format sockettest fails. E.g.
there's a test that parses/formats ::ffff and the format fails like that:
38) Test format ::ffff family AF_UNSPEC ...
Offset 2
Expect [0.0.255.255]
Actual [ffff]
It should be instead:
38) Test format ::ffff family AF_UNSPEC ...
Offset 2
Expect [ffff]
Actual [0.0.255.255]
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The AM_CPPFLAGS setting includes the gnulib headers, which
means we can get some replacement functions defined. Since
virt-login-shell and the NSS module intentionally don't link
to gnulib, these replacement functions causes link failures.
This was seen cross-compiling on Debian for example:
virt-login-shell.o: In function `main':
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:81: undefined reference to `rpl_strerror'
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:66: undefined reference to `rpl_strerror'
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:75: undefined reference to `rpl_strerror'
The only way to avoid these replacement gnulib headers is
to drop the -Ignulib/lib flags. We do still want to use
gnulib for configmake.h and intprops.h, but those can be
included via their full path.
We must also stop using internal.h, since that expects
-Ignulib/lib to be on the include path in order to resolve
the verify.h header.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Eric Blake [Thu, 8 Aug 2019 12:16:42 +0000 (07:16 -0500)]
maint: Update to latest gnulib
Requires adjustments to use verify_expr() which replaces
verify_true(), and to disable the new syntax check
'sc_prohibit_gnu_make_extensions' since we require GNU make.
Eric Blake [Wed, 31 Jul 2019 18:48:54 +0000 (13:48 -0500)]
build: Solve mingw build clash with DATADIR
Commit fed58d83 was a hack to fix a mingw build failure due to header
inclusion order resulting in a clash over the use of DATADIR,
repeating a trick made several other times in the past. Better is to
revert that, and instead use pragmas to avoid the clash in the first
place, regardless of header ordering, solving it for everyone.
Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the code does not refer to any libvirt headers,
except internal.h macros, it does not need to link to
any libvirt code, nor gnulib either. The only thing it
needs is yajl.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The .leases file is currently loaded using the virLease class,
which in turn uses the virJSON parsing code. This pulls in a
heap of libvirt code (logging, hash tables, etc) which we do
not wish to depend on.
This uses the yajl parser code directly, so the only dep is
yajl and plain libc functions.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The .macs file is currently loaded using the virMacMap class,
which in turn uses the virJSON parsing code. This pulls in a
heap of libvirt code (logging, hash tables, objects, etc) which
we do not wish to depend on.
This uses the yajl parser code directly, so the only dep is
yajl and plain libc functions.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
util: get rid of virGetEnv{Allow,Block}SUID functions
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
util: simplify virCommand APIs for env passthrough.
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Thus we only need one API for env passthrough in virCommand.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that none of the libvirt.so code will ever run in a setuid
context, we can remove the virIsSUID() method. The global
initializer function can just inline the check itself. The new
inlined check is slightly stronger as it also looks for a
setgid situation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt-login-shell setuid program is now a tiny piece of code
that only uses standard libc functions, and santizes the execution
environment before invoking the real virt-login-shell-helper.
The latter is thus able to use the normal libvirt.so build,
allowing us to delete the special cut down setuid library build.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt-login-shell binary is a setuid program that takes
no arguments. When invoked it looks at the invoking uid,
resolves it to a username, and finds an LXC guest with the
same name. It then starts the guest and runs the shell in
side the namespaces of the container.
Given this set of tasks the virt-login-shell binary needs
to connect to libvirtd, make various other libvirt API calls.
This is a problem for setuid binaries as various libraries
that libvirt.so links to are not safe. For example, they have
constructor functions which execute an unknown amount of code
that can be influenced by env variables.
For this reason virt-login-shell doesn't use libvirt.so,
but instead links to a custom, cut down, set of source files
sufficient to be a local client only.
This introduces a problem for integrating glib2 into libvirt
though, as once integrated, there would be no way to build
virt-login-shell without an external dependancy on glib2 and
this is definitely not setuid safe.
To resolve this problem, we split the virt-login-shell binary
into two parts. The first part is setuid and does almost
nothing. It simply records the original uid+gid, and then
invokes the virt-login-shell-helper binary. Crucially when
it does this it completes scrubs all environment variables.
It is thus safe for virt-login-shell-helper to link to the
normal libvirt.so. Any things that constructor functions
do cannot be influenced by user control env vars or cli
args.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We'll shortly be renaming the binary to virt-login-shell-helper
and introducing a new tool as virt-login-shell. Renaming the
source file first gives a much more usefull diff for the next
commit.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: fix double error reporting in virt-login-shell
The public API entry points will call virDispatchError which
will print to stderr by default. We then jump to a cleanup
path which calls virDispatchError again.
We tried to stop the entry points printing to stderr, but
incorrectly called virSetErrorFunc. It needs a real function
that is a no-op, not a NULL function.
Once we fix virSetErrorFunc, then we need to use fprintf in
the cleanup path instead of virDispatchError.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: fix crash in virt-login-shell if config doesn't exist
If the 'allowed_users' config setting in virt-login-shell.conf
does not exist, we dereference a NULL pointer resulting in a
crash. We should check for this case and thus ensure the user
is denied access gracefully.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
projects / libvirt.git / log