Coverity already saw through a NULL dereference without these
annotations, and gcc is still too puny to do good NULL analysis.
But clang still benefits (and is easier to run than coverity),
not to mention that adding this bit of documentation to the code
may help future developers remember the constraints.

* src/util/uuid.h (virGetHostUUID, virUUIDFormat): Document
restrictions, for improved static analysis.

Detected by Coverity.  Commit a98d8f0d tried to make uuid debugging
more robust, but missed some APIs.  And on the APIs that it visited,
the mere act of preparing the debug message ends up dereferencing
uuid prior to the null check.  Which means the APIs which are supposed
to gracefully reject NULL arguments now end up with SIGSEGV.

* src/libvirt.c (VIR_UUID_DEBUG): New macro.
(virDomainLookupByUUID, virDomainLookupByUUIDString)
(virNetworkLookupByUUID, virNetworkLookupByUUIDString)
(virStoragePoolLookupByUUID, virStoragePoolLookupByUUIDString)
(virSecretLookupByUUID, virSecretLookupByUUIDString)
(virNWFilterLookupByUUID, virNWFilterLookupByUUIDString): Avoid
null dereference.

Detected by Coverity.  cpumap was allocated with a value of
(unsigned short)*(int), which is an int computation, and then
promotes to size_t.  On a 64-bit platform, this fails if bit
32 of the product is set (because of sign extension giving
a HUGE value to malloc), even though a naive programmer would
assume that since the first value is unsigned, the product
is also unsigned and at most 4GB would be allocated.

Won't bite in practice (the product should never be that large),
but worth using the right types to begin with, so that we are
now computing (unsigned short)*(size_t).

* python/libvirt-override.c (libvirt_virDomainGetVcpus): Use
correct type.

Similar in nature to commit fd21ecfd, which shut up valgrind.

sigaction is apparently a nasty interface for analyzer tools,
at least for how many false positives it generates.

* src/util/command.c (virExecWithHook): Initialize entire var, since
coverity gripes about the (unused and non-standard) sa_restorer.

Detected by Coverity.  The code was doing math on shifted unsigned
char (which promotes to int), then promoting that to unsigned long
during assignment to size.  On 64-bit platforms, this risks sign
extending values of size > 2GiB.  Bug present since commit
489fd3 (v0.6.0).

I'm not sure if a specially-crafted bogus qcow2 image could
exploit this, although it's probably not possible, since we
were already checking for the computed results being within
range of our fixed-size buffer.

* src/util/storage_file.c (qcowXGetBackingStore): Avoid sign
extension.

Coverity 5.3.0 still outputs lots of COVERITY_* variables, but no
longer modifies COVERITY_BUILD_COMMAND in the environment.  Pick
one that seems likely to stay around.

* configure.ac (STATIC_ANALYSIS): Detect newer Coverity.

API virDomainMigrateSetMaxSpeed was introduced since 0.9.0, but
no command in virsh yet.

Since we can't really get useful error reporting from virCommandExec since
it needs to be the last thing we do.

Otherwise the following virFileMakePath will create the directory for
us and fail further ahead, which probably isn't intended.

Add a handshake with the cloned container process to try and detect
if it fails to start.

Add a simple handshake with the lxc_controller process so we can detect
process startup failures. We do this by adding a new --handshake cli arg
to lxc_controller for passing a file descriptor. If the process fails to
launch, we scrape all output from the logfile and report it to the user.

Arranges things similar to the qemu driver. Will allow us to more easily
report command error output.

We will reuse these shortly, and each use should have a different error
message.

Makes it more likely we get useful error output in the logs

Seems reasonable to have all command wrappers in the same place

v2:
    Dont move SetInherit

v3:
    Comment spelling fix
    Adjust WARN0 comment
    Remove spurious #include movement
    Don't include sys/types.h
    Combine virExec enums
Signed-off-by: NCole Robinson <crobinso@redhat.com>

v2:
    Simplify command building
    Handle command building failure

v3:
    Remove unneeded NULL check
Signed-off-by: NCole Robinson <crobinso@redhat.com>

v3:
    Remove obsolete comment
Signed-off-by: NCole Robinson <crobinso@redhat.com>

v2:
    Have virCommand cleanup intermediate process for us

v3:
    Preserve original FD closing behavior
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Those checks are already performed at the public API level.

For backwards compatibility, if no <video> is set but there is a
<graphics> tag, then we add a default <video> according to the
guest type. Add docs to tell the user about this to not make
them confused. Especially if they remove the video (such as via
"virsh edit"), it will be surprised for them to see the video
element is still in domain XML.

virGetVersion itself doesn't take a virConnectPtr, but in order to obtain
the hypervisor version against which libvirt was compiled it is used in
combination with virConnectGetType like this:

hvType = virConnectGetType(conn)
virGetVersion(&libVer, hvType, &typeVer)

When virConnectGetType is called on a remote connection then the remote
driver returns the type of the underlying driver on the server side, for
example QEMU. Then virGetVersion compares hvType to a set of strings that
depend on configure options and returns LIBVIR_VERSION_NUMBER in most
cases. Now this fails in case libvirt on the client side is just compiled
with the remote driver enabled only and the server side has the actual
driver such as the QEMU driver. It just happens to work when the actual
driver is enabled on client and server side. But that's not always true.
I noticed this on FreeBSD:

freebsd# virsh -c qemu+tcp://192.168.178.22/system version
Compiled against library: libvir 0.9.2
error: failed to get the library version
error: this function is not supported by the connection driver: virGetVersion

This is not FreeBSD specific, happens on Windows as well due to the
similar driver support configuration. The problem is that virConnectGetType
returns QEMU, but virGetVersion on the client side only accepts Remote
as hvType due to all other drivers being disabled on the client side.

Daniel P. Berrange suggested to get rid of all the conditional code in
virGetVersion, ignoring the hvType and always setting typeVer to
LIBVIR_VERSION_NUMBER. virConnectGetVersion is supposed to be used to
obtain the hypervisor version.

Annotate the ESX device driver dummy.

Refactor the udev and hal device driver strcuts to match the
common annotation pattern.

* configure.ac docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: updated translations and regenerated

Change the driver comments for proper extraction and values by
the scripts used for documentation

When peer-2-peer migration was invoked by a client supporting
v3, but where the target server only supported v2, we'd not
correctly shutdown the guest.

* src/qemu/qemu_migration.c: Ensure guest is shutdown in
  v2 peer 2 peer migration

The v2 migration protocol doesn't use cookies, so we should not
be raising an error if the cookie parameters are NULL.

* src/qemu/qemu_migration.c: Don't raise error if cookie is NULL

The error code for virKillProcess is returned in the errno variable
not the return value. THis mistake caused the logs to be filled with
errors when shutting down QEMU processes

* src/qemu/qemu_process.c: Fix process kill check.

VirtualBox 4.0.8 changed the registry key layout. Before the version
number was in a Version key. Now the Version key contains %VER% and
the actual version number is in VersionExt now.

Move value lookup code into its own function: vboxLookupRegistryValue.

This commit is safe precisely because there has been no release
for any of the enum values being deleted (they were added post-0.9.1).

After the 0.9.2 release, we can then take advantage of
virDomainModificationImpact in more places.

* include/libvirt/libvirt.h.in (virDomainModificationImpact): New
enum.
(virDomainSchedParameterFlags, virMemoryParamFlags): Delete, since
these were never released, and the new enum works fine here.
* src/libvirt.c	(virDomainGetMemoryParameters)
(virDomainSetMemoryParameters)
(virDomainGetSchedulerParametersFlags)
(virDomainSetSchedulerParametersFlags): Update documentation.
* src/qemu/qemu_driver.c (qemuDomainSetMemoryParameters)
(qemuDomainGetMemoryParameters, qemuSetSchedulerParametersFlags)
(qemuSetSchedulerParameters, qemuGetSchedulerParametersFlags)
(qemuGetSchedulerParameters): Adjust clients.
* tools/virsh.c (cmdSchedinfo, cmdMemtune): Likewise.
Based on ideas by Daniel Veillard and Hu Tao.

This fixes:

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

Both of these complain of a failure to use an image file that resides
on a read-only NFS volume. The function in the DAC security driver
that chowns image files to the qemu user:group before using them
already has special cases to ignore failure of chown on read-only file
systems, and in a few other cases, but it hadn't been checking for
EINVAL, which is what is returned if the qemu user doesn't even exist
on the NFS server.

Since the explanation of EINVAL in the chown man page almost exactly
matches the log message already present for the case of EOPNOTSUPP,
I've just added EINVAL to that same conditional.

This fixes a build failure on MinGW, due to MinGW not supporting dlopen.

Signed-off-by: NNeil Wilson <neil@aldur.co.uk>

Coverity couldn't see that priv is NULL on failure.  But on failure,
we might as well guarantee that callers don't try to free uninitialized
memory.

* src/remote/remote_driver.c (remoteGenericOpen): Even on failure,
pass priv back to caller.

Coverity complained that infd could be -1 at the point where it is
passed to write, when in reality, this code can only be reached if
infd is non-negative.

* src/util/command.c (virCommandProcessIO): Help out coverity.

Detected by Coverity.  Bug introduced in 08106e20 (unreleased).

* src/conf/domain_conf.c (virDomainChannelDefCheckABIStability):
Use correct sizeof operand.