While current on_{poweroff,reboot,crash} action configuration is about
configuring life cycle actions, they can all be considered events and
actions that need to be done on a particular event. Let's generalize the
code by renaming life cycle actions to event actions so that it can be
reused later for non-lifecycle events.

Done with:

sed -i -e "s/no pool with matching uuid/no storage pool with matching uuid/g" src/storage/storage_driver.c
sed -i -e 's/"%s", _("no storage pool with matching uuid")/_("no storage pool with matching uuid %s"), obj->uuid/g' src/storage/storage_driver.c
sed -i -e 's/"%s", _("storage pool is not active")/_("storage pool '%s' is not active"), pool->def->name/g' src/storage/storage_driver.c

And a couple fixups before, during, and after, and a manual inspection
pass to make sure nothing was wonky.

When adding variants of parameter setting APIs which accepted
flags, the existing APIs were all adapted internally to pass
VIR_DOMAIN_AFFECT_CURRENT to the new API. The QEMU impl
qemuSetSchedularParameters was an exception, which instead
used VIR_DOMAIN_AFFECT_LIVE. Change this to match other
compatibility scenarios, so that calling

   virDomainSetSchedularParameters(dom, params, nparams);

Has the same semantics as

   virDomainSetSchedularParametersFlags(dom, params, nparams, 0);

And

   virDomainSetSchedularParametersFlags(dom, params, nparams, VIR_DOMAIN_AFFECT_CURRENT);
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently virNetSocketNew fails because virSetCloseExec fails as there
is no proper implementation for it on Windows at the moment. Workaround
this by pretending that setting close-on-exec on the fd works. This can
be done because libvirt currently lacks the ability to create child
processes on Windows anyway. So there is no point in failing to set a
flag that isn't useful at the moment anyway.

Traverse the whole inheritance hierarchy for dynamic dispatch as it is
already done for the dynamic cast.

Also make AnyType cast errors more verbose.

Reported by Ata Bohra.

Add support to check if a specific interface is active by supporting the
following API function in the udev based virInterface backend:
* virConnectInterfaceIsActive()

Always build all available backends to avoid bit-rot. At run time we
select the correct backend and load it by attempting netcf first and
then udev.

All other backends for virInterface or other HVs implementations of
virInterface list their own names for the name instead of the generic
'Interface' value. This does the same for the netcf based backend.
Also, report any errors during registration.

Add a read-only udev based backend for virInterface. Useful for distros
that do not have netcf support yet. Multiple libvirt based utilities use
a HAL based fallback when virInterface is not available which is less
than ideal. This implements:
* virConnectNumOfInterfaces()
* virConnectListInterfaces()
* virConnectNumOfDefinedInterfaces()
* virConnectListDefinedInterfaces()
* virConnectListAllInterfaces()
* virConnectInterfaceLookupByName()
* virConnectInterfaceLookupByMACString()

The code was reporting raw exit status without decoding it into
normal vs. signal exit.  virCommandRun already does this, but
with a different error type, so all we have to do is recast
the error to the correct type.
Reported by li guang.

* src/util/hooks.c (virHookCall): Simplify.

As a side effect of changes in the functions virGetUserID and
virGetGroupID, the user and group configurations for DAC in qemu.conf
are now able to accept both names and IDs, supporting a leading plus
sign to ensure that a numeric value will not be interpreted as a name.

This patch updates the comments in qemu.conf, including a description of
this new behavior.

With our latest s/[a-z]+ReportError/virReportError/ rewrite
(47ab34e2) we forgot to update arm part of the code.

With the recent introduction of QMP capabilities probing, libvirt failed
to detect support for QXL graphics in QEMU 1.2 and newer. In addition to
fixing that, this patch also causes libvirt to detect QXL support for
qemu-kvm-0.13.0, which doesn't advertise it in -help output but mentions
it in device list. Since qemu-kvm-0.13.0 supported -spice, it looks like
not having qxl in -help was a bug.

I was using qemu-monitor-command during development, and found it quite
hard to use.  Compare the results of this patch on ease of reading:

$ virsh qemu-monitor-command          dom '{"execute":"query-version"}'
{"return":{"qemu":{"micro":1,"minor":12,"major":0},"package":"(qemu-kvm-0.12.1.2)"},"id":"libvirt-7683"}

$ virsh qemu-monitor-command --pretty dom '{"execute":"query-version"}'
{
    "return": {
        "qemu": {
            "micro": 1,
            "minor": 12,
            "major": 0
        },
        "package": "(qemu-kvm-0.12.1.2)"
    },
    "id": "libvirt-7674"
}

* tools/virsh-host.c (cmdQemuMonitorCommand): New option.
* tools/virsh.pod (qemu-monitor-command): Document it.

The functions virGetUserID and virGetGroupID are now able to parse
user/group names and IDs in a similar way to coreutils' chown. So, user
and group parsing in security_dac can be simplified.

This patch updates virGetUserID and virGetGroupID to be able to parse a
user or group name in a similar way to coreutils' chown. This means that
a numeric value with a leading plus sign is always parsed as an ID,
otherwise the functions try to parse the input first as a user or group
name and if this fails they try to parse it as an ID.

This patch includes Peter Krempa's changes to correctly handle errors
returned by getpwnam_r and getgrnam_r.

curl_global_init is not thread-safe. curl_easy_init might call
curl_global_init when it was no called before. But curl_easy_init
can be called from different threads by the ESX driver. Therefore,
call curl_global_init from virInitialize to stop curl_easy_init from
calling it.

Reported by Benjamin Wang.

When both kvmclock and kvm_pv_eoi are configured (either disabled or
enabled) libvirt will generate invalid CPU specification due to the
fact that even though kvmclock causes the CPU to be specified, it
doesn't set have_cpu flag to true (and the new kvm_pv_eoi as well).
This patch fixes the issue and adds a test exactly for that to show
that it is fixed correctly (and also to keep it that way in the future
of course).

The variable that is set in the script is with_dbus, not have_dbus.

libvirt_ulonglongUnwrap requires the integer type of python obj.
But libvirt_longlongUnwrap still could handle python obj of
Pyfloat_type which causes the float value to be rounded up
to an integer.

For example
 >>> dom.setSchedulerParameters({'vcpu_quota': 0.88})
 0
libvirt_longlongUnwrap treats 0.88 as a valid value 0

However
 >>> dom.setSchedulerParameters({'cpu_shares': 1000.22})
libvirt_ulonglongUnwrap will throw out an error
"TypeError: an integer is required"

The patch make this consistent.

libvirt_virDomainGetVcpus: add error handling, return -1 instead of None
libvirt_virDomainPinVcpu and libvirt_virDomainPinVcpuFlags:
  check the type of argument
  make use of libvirt_boolUnwrap

  Set bitmap according to these values which are contained in given
  argument of vcpu tuple and turn off these bit corresponding to
  missing vcpus in argument tuple

  The original way ignored the error info from PyTuple_GetItem
  if index is out of range.
  "IndexError: tuple index out of range"
  The error message will only be raised on next command in interactive mode.

libcurl uses a SIGALRM in combination with sigsetjmp/siglongjmp to be
able to abort a DNS lookup when it takes too long. The problem with this
in a multi-threaded application is that the signal handler for SIGALRM
and the call to siglongjmp can be executed on a thread that is different
from the one that initially did the SIGALRM setup and the call to
sigsetjmp. In the reported case this triggered a segfault.

Disable libcurl's use of signals to avoid this situation. This has the
disadvantage of losing the ability to abort synchronous DNS lookups which
might result in libcurl getting stuck in a DNS lookup in the worst case.
When libcurl was build with an asynchronous DNS backend such as c-ares
then there is no problem because the timeout mechanism works without
signals here anyway.

Reported by Benjamin Wang.

The output buffer for virFileReadAll was too small for systems with
more than 30 CPUs which leads to a log entry and incorrect behavior.
The new size will be sufficient for the current
architectural limits.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

This reverts part of commit 5468594f; the perl changes in that
patch were sufficient.  Since libvirt.syms is already a generated
file created in part from libvirt_private.syms, we don't need a
second pass over libvirt_private.syms in isolation.

* src/Makefile.am: Undo addition of check-private-symfile.

Currently, we are checking if libvirt.so contains public symbols.
However, sometimes we rename an internal symbol and forget to
change libvirt_private.syms accordingly. Hence, it's safer to check
for internal symbols as well.

I noticed that in two places, we require util-linux, and in a third,
we require util-linux-ng.  On Fedora (I tested F15 through rawhide),
util-linux-ng is obsoleted by util-linux; on RHEL 6, util-linux
is obsoleted by util-linux-ng.  That is, on either platform, either
name will get you the correct package installed (where the preferred
name on fedora is util-linux, and on RHEL 6 is util-linux-ng).  But
on RHEL 5, there is no util-linux-ng

* libvirt.spec.in (Requires): Use util-linux, not util-linux-ng.

After it got renamed to virProcessKill (cf470068)
it is no longer needed in the private syms file.

Use of the wrong attribute name caused the table of contents to
be useless.  Fix suggested by Daniel P. Berrange.

* docs/migration.html.in: Use correct anchoring attribute.

Getting a artifact into Maven central has a lot of restrictions as
where the artifact should be hosted.

This seemed like a big hassle which we don't want to go through now.

Document a way for users to use libvirt.org as a repository so they can
fetch the Java bindings with maven.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

Correct the check for the return value of virStrcpyStatic()
when copying port-profile names. Fixes Open vSwitch ports
which utilize port-profiles from network definitions.
Signed-off-by: NKyle Mestery <kmestery@cisco.com>

Based on a report that phyp is undocumented:
https://www.redhat.com/archives/libvirt-users/2012-July/msg00013.html

* docs/drvphyp.html.in (phyp): New file.
* docs/drivers.html.in: List it.

Several gnulib tests were failing 'make check', and compilation with
CFLAGS=-g failed due to a gcc 4.2.1 limitation.

* .gnulib: Update to latest, for gcc 4.2 support and fixed FreeBSD tests.

This patch adds a brief description about labels for each security
driver.

The DAC driver is missing parsing of group and user names for DAC labels
and currently just parses uid and gid. This patch extends it to support
names, so the following security label definition is now valid:

  <seclabel type='static' model='dac' relabel='yes'>
      <label>qemu:qemu</label>
      <imagelabel>qemu:qemu</imagelabel>
  </seclabel>

When it tries to parse an owner or a group, it first tries to resolve it as
a name, if it fails or it's an invalid user/group name then it tries to
parse it as an UID or GID. A leading '+' can also be used for both owner and
group to force it to be parsed as IDs, so the following example is also
valid:

  <seclabel type='static' model='dac' relabel='yes'>
      <label>+101:+101</label>
      <imagelabel>+101:+101</imagelabel>
  </seclabel>

This ensures that UID 101 and GUI 101 will be used instead of an user or
group named "101".

Commit c579d6b3 added a sledgehammer to silence spurious warnings from
gcc 4.2, but in the process, it also silenced useful warnings from
gcc 4.3 through 4.5.  As a result, a bug slipped in to commit 0caccb58.

Tested with FreeBSD (gcc 4.2.1), RHEL 6.3 (gcc 4.4), and F17 (gcc 4.7.2),
where the former didn't trip on spurious warnings, and where the latter
two detected a revert of 2b804cfa.

* m4/virt-compile-warnings.m4 (-Wno-format): Probe for the actual
spurious message, to once again allow gcc 4.4 to use -Wformat.

Introduced in commit 0caccb58.

  CC     libvirt_driver_qemu_impl_la-qemu_capabilities.lo
../../src/qemu/qemu_capabilities.c: In function 'qemuCapsInitQMP':
../../src/qemu/qemu_capabilities.c:2327:13: error: format '%d' expects argument of type 'int', but argument 8 has type 'const char *' [-Werror=format]

* src/qemu/qemu_capabilities.c (qemuCapsInitQMP): Use correct format.

Since libvirt switched to QMP capabilities probing recently, it starts
QEMU process used for this probing with -daemonize, which means
virCommandAbort can no longer reach these processes. As a result of
that, restarting libvirtd will leave several new QEMU processes behind.
Let's use QEMU's -pidfile and use it to kill the process when QMP caps
probing is done.

When doing snapshots, the filesystem freeze function used the agent
entering function that expects the qemud_driver unlocked. This might
cause a deadlock of the qemu driver if the agent does not respond.

The only call path of this function has the qemud_driver locked, so this
patch changes the entering functions to those expecting the driver
locked.