Man page, help output and also parsing is sorted in order to find
options smoothly.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This resolves a Coverity RESOURCE_LEAK issue introduced by commit
id 'de6fa535' where the virSCSIDeviceSetUsedBy() didn't VIR_FREE
the 'copy' or possibly VIR_STRDUP()'d values.  It also ensures that
the VIR_APPEND_ELEMENT is successful...

Test it once with SELinux enabled and once with it disabled.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

If SELinux is compiled into libvirt but it is disabled on the host,
libvirtd logs:

  error : virIdentityGetSystem:173 : Unable to lookup SELinux process
  context: Invalid argument

on each and every client connection.

Use is_selinux_enabled() to skip retrieval of the process's SELinux
context if SELinux is disabled.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

With the previous commit's securityselinuxhelper enhancements, the
SELinux security manager can be tested even without SELinux enabled on
the test system.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Add fake implementations of:

- is_selinux_enabled
- security_disable
- selinux_virtual_domain_context_path
- selinux_virtual_image_context_path
- selinux_lxc_contexts_path
- selabel_open
- selabel_close
- selabel_lookup_raw

The selabel_* functions back onto the real implementations if SELinux is
enabled on the test system, otherwise we just implement a fake selabel
handle which errors out on all labelling lookups.

With these changes in place, securityselinuxtest and
securityselinuxlabeltest don't need to skip all tests if SELinux isn't
available; they can exercise much of the security manager code.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Libvirt tarball contains po/stamp-po file which prevents any po/*.gmo
file to be regenerated even if a corresponding po/*.po file is newer. By
removing the stamp-po file, all *.gmo files are properly updated if
required. This allows downstreams to provide patches that update
translations.

When domain is started with setting that cannot be done, i.e. those
that require cgroups, there is no error reported and it succeeds
without any message whatsoever.

When setting with API, virsh, an error is reported, but only due to
the fact that no cgroups are mounted (priv->cgroup == NULL).

Given the above it seems reasonable to reject such unsupported
settings.

This patch effectively changes the error message from:

$ virsh -c qemu:///session schedinfo dummy
Scheduler      : Unknown
error: Requested operation is not valid: cgroup CPU controller is not mounted

to:

$ virsh -c qemu:///session schedinfo dummy
Scheduler      : Unknown
error: Operation not supported: CPU tuning is not available in session mode

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1023366Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

As of commit 46ec5f85, the conn.lock mutex does not need to be held
when calling any vir*Dispose() function in datatypes.c (via virObjectUnref()).
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Coverity spotted that 'nfdlist' (ssize_t) could be -1, but that we
were using 'i' (size_t) to iterate over the list at cleanup, with
crashing results because it promotes to a really big unsigned number.

* tools/virt-login-shell.c (main): Avoid treating -1 as unsigned.
Signed-off-by: NEric Blake <eblake@redhat.com>

configure check for character devices lock path calls
AC_DEFINE_UNQUOTED for VIR_CHRDEV_LOCK_FILE_PATH even if
$with_chrdev_lock_files = "no".

So the locking code in conf/virchrdev.c:

 #ifdef VIR_CHRDEV_LOCK_FILE_PATH

is compiled in even if it shouldn't, because VIR_CHRDEV_LOCK_FILE_PATH
is defined as "no", so it tries to create lock files with strange
lock path like 'no/LCK..'.

Fix that by calling AC_DEFINE_UNQUOTED only if $with_chrdev_lock_files
is not 'no'.

The qemuMonitorJSONBlockJob handles a few errors internally. If qemu
returns a different error we would report a rather unhelpful message:

 $ virsh blockpull gluster-job vda --base /dev/null
 error: internal error: Unexpected error

As the actual message from qemu contains a bit more info, let's use it
to report something a little more useful:

 $ virsh blockpull gluster-job vda --base /dev/null
 error: internal error: Unexpected error: (GenericError) 'Base '/dev/null' not found'

With most of our storage backends it's possible to have two separate
volume keys to point to a single volume. (By creating sym/hard-links to
local files or by mounting remote filesystems to two different locations
and creating pools on top of them) Document this possibility.

In storageVolLookupByPath the provided path is "sanitized" at first.
This removes some extra slashes and stuff. When the lookup of the volume
fails the original path is used which makes it hard to trace errors in
some cases.

Improve the error message to print the sanitized path along with the
user provided path if they are not equal.

When looking up a volume by path on a non-local filesystem don't use the
"cleaned" path that might be mangled in such a way that it will differ
from a path provided by a storage backend.

Skip the cleanup step for gluster, sheepdog and RBD.

Pools that are not backed by files in the filesystem cause problems with
some APIs. Error out when attempting to upload a volume in such a pool
as currently we expect a local file representation for it.

If a user specifies the pool explicitly, we should make sure to point
out that it's inactive instead of falling back to lookup by key/path and
failing at the end. Also if the pool isn't found there's no use in
continuing the lookup.

This changes the error in case the user-selected pool is inactive from:

 $ virsh vol-upload --pool inactivepool --vol somevolname volcontents
 error: failed to get vol 'somevolname'
 error: Storage volume not found: no storage vol with matching path
 somevolname

To a more descriptive:

 $ virsh vol-upload --pool inactivepool --vol somevolname volcontents
 error: pool 'inactivepool' is not active

And in case a user specifies an invalid pool from:

 $ virsh vol-upload --pool invalidpool --vol somevolname volcontents
 error: failed to get pool 'invalidpool'
 error: failed to get vol 'somevolname', specifying --pool might help
 error: Storage volume not found: no storage vol with matching path somevolname

To something less confusing:

 $ virsh vol-upload --pool invalidpool --vol somevolname volcontents
 error: failed to get pool 'invalidpool'
 error: Storage pool not found: no storage pool with matching name 'invalidpool'

Signed-off-by: NChunyan Liu <cyliu@suse.com>

Specify which driver and which domain in used_by area to avoid conflict among
different drivers.
Signed-off-by: NChunyan Liu <cyliu@suse.com>

The reason for these is that aa-status doesn't show the process using
the profile as they are in another namespace.

If apparmor security driver is enabled in either qemu or lxc
driver configuration and libvirtd starts before AppArmor, it will fail.

use_apparmor() was first designed to be called from withing libvirtd,
but libvirt_lxc also uses it. in libvirt_lxc, there is no need to check
whether to use apparmor or not: just use it if possible.

In qemuMonitorJSONExtractCPUInfo an error message hinted on missing
character device data which is wrong.

Also a comment states that only qemu-kvm tree includes the thread_id
field. This is no longer true.

https://bugzilla.redhat.com/show_bug.cgi?id=1071264

Reverting of external snapshots is not supported currently. The check
that is present doesn't properly check for all aspects that make a
snapshot external. Use virDomainSnapshotIsExternal() to do the check.

As I did previously in 4f588a1b, libvirt needs to set virtio vectors.
Previously, we were advised to use vectors=N, where

N = 2 * (number of queues) + 1

However, just recently this advisory has changed on the Multiquue wiki
page [1] to:

N = 2 * (number of queues) + 2

1: http://www.linux-kvm.org/page/Multiqueue#Enable_MQ_featureSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

If systemd is installed, but is not the init system,
systemd-machined fails with an unhelpful error message:
Launch helper exited with unknown return code 1

Currently we only check if the "machine1" service is
available (in ListActivatableNames).
Also check if "systemd1" service is registered with DBus
(ListNames).

This fixes https://bugs.gentoo.org/show_bug.cgi?id=493246#c22

Introduce virDBusIsServiceInList which can be used to call other
methods for listing services (ListNames), not just ListActivatableNames.

No functional change, fixed the 'Retruns' typo.

Include dlfcn.h before checking if RTLD_NEXT is defined

This is actually a proper setting since we're not checking
session-mode related XMLs.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 631923e7 used a few macros from sys/wait.h without including
it. On Linux, they were also defined in stdlib.h, but on FreeBSD
the build failed:

../../tests/commandtest.c: In function 'test1':
warning: implicit declaration of function 'WIFEXITED'
warning: nested extern declaration of 'WIFEXITED' [-Wnested-externs]

Jenkins pointed out that the previous commit violates syntax
check when cppi is installed.

* src/nwfilter/nwfilter_dhcpsnoop.c (SNOOP_POLL_MAX_TIMEOUT_MS):
Update indentation.
Signed-off-by: NEric Blake <eblake@redhat.com>

Libpcap 1.5 requires a larger buffer than previous pcap versions.
Adjust the size of the buffer to 128kb.

This patch should address symptoms in BZ 1071181 and BZ 731059
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Display the pcap error message in the log.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Cap the poll timeout in the DHCP Snooping code to a max. of 10 seconds
to not hold up the libvirt shutdown longer than this.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

'virsh lxc-enter-namespace' does not have a way to reflect exit
status to the caller in single-command mode, but we might as well
at least report the exit status.  Prior to this patch,

$ virsh -c lxc:/// lxc-enter-namespace shell /bin/sh 'exit 3'; echo $?
1

now it gives some details:

$ virsh -c lxc:/// lxc-enter-namespace shell /bin/sh -c 'exit 3'; echo $?
error: internal error: Child process (31557) unexpected exit status 3
1

Also useful:

$ virsh -c lxc:/// lxc-enter-namespace shell /bin/sh -c 'kill $$'; echo $?
error: internal error: Child process (31585) unexpected fatal signal 15
1

* tools/virsh-domain.c (cmdLxcEnterNamespace): Avoid magic numbers.
Dispatch any error.
* tools/virsh.pod: Document that non-zero exit status is collapsed.
Signed-off-by: NEric Blake <eblake@redhat.com>

virt-login-shell was exiting with status 0, regardless of what the
wrapped shell returned.  This is unkind to users; we should behave
more like env(1), nice(1), su(1), and other wrapper programs, by
preserving the invoked application's status (which includes the
distinction between death due to signal vs. normal death).

* tools/virt-login-shell.c (main): Pass through child exit status.
* tools/virt-login-shell.pod: Document exit status.
Signed-off-by: NEric Blake <eblake@redhat.com>