Continue consolidation of process functions by moving some
helpers out of command.{c,h} into virprocess.{c,h}
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 9467ab6074)
Change "Pid" to "Process" to align with the virProcessKill
API naming prefix
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 0fb58ef5cd)
https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.
* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/; If/. If/
Based exclusively on work by Eric Blake in a patch posted with the same
subject. However some modifications related to comments and my plans to
add another backend.
Added WITH_INTERFACE as the only automake variable deciding whether to
build the driver and using WITH_NETCF to identify that we're wanting to
use the netcf library as the backend.
* configure.ac: Added with_interface
* src/interface/netcf_driver.c: Renamed..
* src/interface/interface_backend_netcf.c: ..to this to match storage.
* src/interface/netcf_driver.h: Renamed..
* src/interface/interface_driver.h: ..to this.
* daemon/Makefile.am: Respect WITH_INTERFACE and WITH_NETCF.
* libvirt.spec.in: Add RPM support for --with-interface
Recent work to improve support for loadable driver modules introduced
a regression in the xen driver. The legacy xen driver is now a
stateful, libvirtd driver but was not being registered when building
without driver modules.
A slight behavior change was also noted in the xen drivers when
built as driver modules. Previously, explicitly specifying a
connection URI was not necessary, but now
Compiled against library: libvirt 0.10.0
Using library: libvirt 0.10.0
Using API: QEMU 0.10.0
error: failed to get the hypervisor version
error: internal error Cannot find suitable emulator for x86_64
The xen drivers need to be registered before the qemu driver since
the qemu driver will return success with a null connection URI.
This ordering is safe since the xen drivers will decline when not
running the xen kernel.
The commits d575679401 and
080bf330e3 made use directly of
macro defined in recent linux netlink version. Make those
part conditional on the definition
* daemon/libvirtd.c: do not use NETLINK_ROUTE and NETLINK_KOBJECT_UEVENT
without some check first
This patch introduce virNetlinkEventServiceStopAll() to stop
all the monitors to receive netlink messages for libvirtd.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
This patch improve all the API in virnetlink.c to support
all kinds of netlink protocols, and make all netlink sockets
be able to join in groups.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
When running libvirtd from a build directory, libvirtd would load lock
drivers from system directory unless explicitly overridden by setting
LIBVIRT_LOCK_MANAGER_PLUGIN_DIR environment variable. Since we already
autodetect driver directory if libvirt is build with driver modules, we
can use the same trick to automagically set lock driver directory.
Currently there is a hook function that is invoked when a
new client connection comes in, which allows an app to
setup private data. This setup will make it difficult to
serialize client state during process re-exec(). Change to
a model where the app registers a callback when creating
the virNetServerPtr instance, which is used to allocate
the client private data immediately during virNetClientPtr
construction.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When running libvirtd from a build directory on a system with unmodified
libtool, libvirtd's binary is not renamed as "lt-libvirtd". Check for
"/daemon/.libs/libvirtd" in addition to "lt-libvirtd".
Remove the use of a manually run virLogStartup and
virNodeSuspendInitialize methods. Instead make sure they
are automatically run using VIR_ONCE_GLOBAL_INIT
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
WITH_INTERFACE is not defined, it should be WITH_NETCF there to load
the interface driver.
Eric posted patch weeks ago to resolve the problems in the whole
build system, but it's not finalised yet:
https://www.redhat.com/archives/libvir-list/2012-June/msg01299.html
I'm going to simply fix the wrong macro name here so that the
interface driver could loaded, and continue the work on the listing
API for interface driver.
When running directly from GIT, libvirtd attempts to locate
the directory containing loadable modules. This currently
only works if executing libvirtd with a CWD inside the libvirt
source tree. Switch to locate based on the path to the current
binary instead
Per the FSF address could be changed from time to time, and GNU
recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
You should have received a copy of the GNU General Public License
along with Foobar. If not, see <http://www.gnu.org/licenses/>.
This patch removes the explicit FSF address, and uses above instead
(of course, with inserting 'Lesser' before 'General').
Except a bunch of files for security driver, all others are changed
automatically, the copyright for securify files are not complete,
that's why to do it manually:
src/security/security_selinux.h
src/security/security_driver.h
src/security/security_selinux.c
src/security/security_apparmor.h
src/security/security_apparmor.c
src/security/security_driver.c
The callback that is invoked when a new RPC client is
initialized does not have any opaque parameter. Add
one so that custom data can be passed into the callback
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Previous commit
commit 32a9aac2e0
Author: William Jon McCann <william.jon.mccann@gmail.com>
Date: Thu May 3 12:36:27 2012 -0400
Use XDG Base Directories instead of storing in home directory
Accidentally changed the umask when creating /var/run/libvirt
to 077. This prevents /var/run/libvirt being readable by non-root,
which is required for non-root to connect to libvirtd. Fix the
code so that umask 077 is only used for the non-privileged libvirtd
instance.
Only the non-privileged libvirtd instance uses $HOME. So avoid
running the code for migrating to XDG directories unless using
a non-privileged libvirtd
Commit 1c275e9a accidentally dropped the storage driver from
libvirtd, because it depended on a C preprocessor macro that
was not defined. Furthermore, if you do './configure
--without-storage-dir --with-storage-disk' or any other combination
where you explicitly build a subset of storage backends excluding
the dir backend, then the build is broken.
Based on analysis by Osier Yang.
* configure.ac (WITH_STORAGE): Define top-level conditional.
* src/Makefile.am (mod_LTLIBRARIES): Build driver even when
storage_dir is disabled.
* daemon/libvirtd.c: Pick up storage driver for any backend, not
just dir.
* daemon/Makefile.am (libvirtd_LDADD): Likewise.
Remove the uid param from virGetUserConfigDirectory,
virGetUserCacheDirectory, virGetUserRuntimeDirectory,
and virGetUserDirectory
These functions were universally called with the
results of getuid() or geteuid(). To make it practical
to port to Win32, remove the uid parameter and hardcode
geteuid()
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* daemon/libvirtd.c: Set custom driver module dir if the current
binary name is 'lt-libvirtd' (indicating execution directly
from GIT checkout)
* src/driver.c, src/driver.h, src/libvirt_driver_modules.syms: Add
virDriverModuleInitialize to allow driver module location to
be changed
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The driver modules all use symbols which are defined in libvirt.so.
Thus for loading of modules to work, the binary that libvirt.so
is linked to must export its symbols back to modules. If the
libvirt.so itself is dlopen()d then the RTLD_GLOBAL flag must
be set. Unfortunately few, if any, programming languages use
the RTLD_GLOBAL flag when loading modules :-( This means is it
not practical to use driver modules for any libvirt client side
drivers (OpenVZ, VMWare, Hyper-V, Remote client, test).
This patch changes the build process so only server side drivers
are built as modules (Xen, QEMU, LXC, UML)
* daemon/libvirtd.c: Add missing load of 'interface' driver
* src/Makefile.am: Only build server side drivers as modules
* src/libvirt.c: Don't load any driver modules
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Due to a bug in editing /etc/sysconfig/libvirtd, VDSM was causing
libvirt processes to run with the following command line args
/usr/sbin/libvirtd --listen '#' 'by vdsm'
While it correctly rejects any invalid option flags, libvirtd
was not rejecting any non-option command line arguments
* daemon/libvirtd.c: Reject non-option argv
The current unprivileged user libvirtd sockets are in the abstract
namespace. This has a number of problems
- You can't connect to them remotely using the nc/ssh tunnel
- This is not portable for OS-X, BSD & probably others
- Parent directory permissions don't apply
As defined in:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
This offers a number of advantages:
* Allows sharing a home directory between different machines, or
sessions (eg. using NFS)
* Cleanly separates cache, runtime (eg. sockets), or app data from
user settings
* Supports performing smart or selective migration of settings
between different OS versions
* Supports reseting settings without breaking things
* Makes it possible to clear cache data to make room when the disk
is filling up
* Allows us to write a robust and efficient backup solution
* Allows an admin flexibility to change where data and settings are stored
* Dramatically reduces the complexity and incoherence of the
system for administrators
DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue logic itself.
The forthcoming FirewallD integration also requires a
dbus connection with event loop integration. Thus we need
to pull the current event loop glue out of the HAL driver.
Thus we create src/util/virdbus.{c,h} files. This contains
just one method virDBusGetSystemBus() which obtains a handle
to the single shared system bus instance, with event glue
automagically setup.
Rename existing daemonConfigLoad API to daemonConfigLoadFile and
add an alternative daemonConfigLoadData
* daemon/libvirtd-config.c, daemon/libvirtd-config.h: Add
daemonConfigLoadData and rename daemonConfigLoad to
daemonConfigLoadFile
* daemon/libvirtd.c: Update for renamed API
To enable creation of unit tests, split the libvirtd config file
loading code out into separate files.
* daemon/libvirtd.c: Delete config loading code / structs
* daemon/libvirtd-config.c, daemon/libvirtd-config.h: Config
file loading APIs
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The code is splattered with a mix of
sizeof foo
sizeof (foo)
sizeof(foo)
Standardize on sizeof(foo) and add a syntax check rule to
enforce it
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Don't advertise information on the network without consent of
the user, either through manual configuration, or a user
interface that drives this option.
* Since libvirtd must be configured for network access anyway
(for all but ssh), this setting was not useful "out of the box",
so changing this default setting does not remove "out of the box"
functionality.
No thanks to 64-bit windows, with 64-bit pid_t, we have to avoid
constructs like 'int pid'. Our API in libvirt-qemu cannot be
changed without breaking ABI; but then again, libvirt-qemu can
only be used on systems that support UNIX sockets, which rules
out Windows (even if qemu could be compiled there) - so for all
points on the call chain that interact with this API decision,
we require a different variable name to make it clear that we
audited the use for safety.
Adding a syntax-check rule only solves half the battle; anywhere
that uses printf on a pid_t still needs to be converted, but that
will be a separate patch.
* cfg.mk (sc_correct_id_types): New syntax check.
* src/libvirt-qemu.c (virDomainQemuAttach): Document why we didn't
use pid_t for pid, and validate for overflow.
* include/libvirt/libvirt-qemu.h (virDomainQemuAttach): Tweak name
for syntax check.
* src/vmware/vmware_conf.c (vmwareExtractPid): Likewise.
* src/driver.h (virDrvDomainQemuAttach): Likewise.
* tools/virsh.c (cmdQemuAttach): Likewise.
* src/remote/qemu_protocol.x (qemu_domain_attach_args): Likewise.
* src/qemu_protocol-structs (qemu_domain_attach_args): Likewise.
* src/util/cgroup.c (virCgroupPidCode, virCgroupKillInternal):
Likewise.
* src/qemu/qemu_command.c(qemuParseProcFileStrings): Likewise.
(qemuParseCommandLinePid): Use pid_t for pid.
* daemon/libvirtd.c (daemonForkIntoBackground): Likewise.
* src/conf/domain_conf.h (_virDomainObj): Likewise.
* src/probes.d (rpc_socket_new): Likewise.
* src/qemu/qemu_command.h (qemuParseCommandLinePid): Likewise.
* src/qemu/qemu_driver.c (qemudGetProcessInfo, qemuDomainAttach):
Likewise.
* src/qemu/qemu_process.c (qemuProcessAttach): Likewise.
* src/qemu/qemu_process.h (qemuProcessAttach): Likewise.
* src/uml/uml_driver.c (umlGetProcessInfo): Likewise.
* src/util/virnetdev.h (virNetDevSetNamespace): Likewise.
* src/util/virnetdev.c (virNetDevSetNamespace): Likewise.
* tests/testutils.c (virtTestCaptureProgramOutput): Likewise.
* src/conf/storage_conf.h (_virStoragePerms): Use mode_t, uid_t,
and gid_t rather than int.
* src/security/security_dac.c (virSecurityDACSetOwnership): Likewise.
* src/conf/storage_conf.c (virStorageDefParsePerms): Avoid
compiler warning.
This code adds a netlink event interface to libvirt.
It is based upon the event_poll code and makes use of
it. An event is generated for each netlink message sent
to the libvirt pid.
Signed-off-by: D. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
Valgrind detected a pipe fd leak before the parent exits on success,
introduced in commit 4296cea; by itself, the leak is not bad, since
we immediately called _exit(), but we might as well be clean to make
valgrind analysis easier. Meanwhile, if the daemon grandchild detects
an error, the parent failed to flush the error message before exiting.
Also, we had the possibility of both parent and child returning to the
caller, such that the user could see duplicated reports of failure
from the two return paths. And we might as well be robust to the
(unlikely) situation of being started with stdin closed.
* daemon/libvirtd.c (daemonForkIntoBackground): Use exit if an
error message was generated, avoid fd leaks for valgrind's sake,
avoid returning to caller in both parent and child, and don't
close a just-dup'd stdin.
Based on a report by Alex Jia.
* How to reproduce?
% service libvirtd stop
% valgrind -v --track-fds=yes /usr/sbin/libvirtd --daemon
* Actual valgrind result:
==16804== FILE DESCRIPTORS: 7 open at exit.
==16804== Open file descriptor 7:
==16804== at 0x321FAD8B87: pipe (in /lib64/libc-2.12.so)
==16804== by 0x41F34D: daemonForkIntoBackground (libvirtd.c:186)
==16804== by 0x4207A0: main (libvirtd.c:1420)
Signed-off-by: Alex Jia <ajia@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Based on a report by Coverity. waitpid() can leak resources if it
fails with EINTR, so it should never be used without checking return
status. But we already have a helper function that does that, so
use it in more places.
* src/lxc/lxc_container.c (lxcContainerAvailable): Use safer
virWaitPid.
* daemon/libvirtd.c (daemonForkIntoBackground): Likewise.
* tests/testutils.c (virtTestCaptureProgramOutput, virtTestMain):
Likewise.
* src/libvirt.c (virConnectAuthGainPolkit): Simplify with virCommand.
This is a regression introduced by new RPC codes, previously
we advertise the service via ssh even if the daemon doesn't
listen on TLS port (TCP is not choosed). Now the service is
only advertised when it listens on TLS or TCP port. This breaks
upper layer apps which intends to discover the service, such
as virt-manager.
This is a bit painful for example when starting virt-manager
it tends to clutter libvirtd.log with invalid operation on cpu pinning
for defined but not running domains. A priori those kind of errors
don't indicate an error when executing the command but on a precondition
for running the API, and honnestly while the application should report
it, logging it as an error in libvirtd.log is not really useful,
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=590807
* daemon/libvirtd.c: extend daemonErrorLogFilter() to filter out
errors of type VIR_ERR_OPERATION_INVALID
This patch annotates APIs with low or high priority.
In low set MUST be all APIs which might eventually access monitor
(and thus block indefinitely). Other APIs may be marked as high
priority. However, some must be (e.g. domainDestroy).
For high priority calls (HPC), there are some high priority workers
(HPW) created in the pool. HPW can execute only HPC, although normal
worker can process any call regardless priority. Therefore, only those
APIs which are guaranteed to end in reasonable small amount of time
can be marked as HPC.
The size of this HPC pool is static, because HPC are expected to end
quickly, therefore jobs assigned to this pool will be served quickly.
It can be configured in libvirtd.conf via prio_workers variable.
Default is set to 5.
To mark API with low or high priority, append priority:{low|high} to
it's comment in src/remote/remote_protocol.x. This is similar to
autogen|skipgen. If not marked, the generator assumes low as default.
When libvirtd is running at non-root user, it won't create ${HOME}/.libvirt.
It will show error message:
17:44:16.838: 7035: error : virPidFileAcquirePath:322 : Failed to open pid file
Signed-off-by: Xu He Jie <xuhj@linux.vnet.ibm.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
