%systemd_preun macro cannot be split into several lines.

https://bugzilla.redhat.com/show_bug.cgi?id=1136736Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The 'elem' variable along with the domain object would be leaked when
taking the error path.

Found by coverity.

Currently, there is one flag passed in during macvtap creation
(withTap) -- Let's convert this field to an unsigned int flag
field for future expansion.
Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: new localizations and regenerate pos

While qemu definitely caps granularity to 64 MiB, it places no
limits on buf-size.  On a machine beefy enough for lots of
memory, a buf-size larger than 2 GiB is feasible, so we should
pass a 64-bit parameter.

* include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_COPY_BUF_SIZE):
Allow 64 bits.
Signed-off-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The cleanup in commit cf976d9d used secdef->label to label the tap
FDs, but that is not possible since it's process-only label (svirt_t)
and not a object label (e.g. svirt_image_t).  Starting a domain failed
with EPERM, but simply using secdef->imagelabel instead of
secdef->label fixes it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since 1b807f92, connecting with virsh to an already running session
libvirtd fails with:
$ virsh list --all
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to
'/run/user/1000/libvirt/libvirt-sock': Transport endpoint is already
connected

This is caused by a logic error in virNetSocketNewConnectUnix: even if
the connection to the daemon socket succeeded, we still try to spawn the
daemon and then connect to it.
This commit changes the logic to not try to spawn libvirtd if we
successfully connected to its socket.

Most of this commit is whitespace changes, use of -w is recommended to
look at it.

Currently, after calling commands to create a new volumes,
virStorageBackendZFSCreateVol calls virStorageBackendZFSFindVols that
calls virStorageBackendZFSParseVol.

virStorageBackendZFSParseVol checks if a volume already exists by
trying to get it using virStorageVolDefFindByName.

For a just created volume it returns NULL, so volume is reported as
new and appended to pool->volumes. This causes a volume to be listed
twice as storageVolCreateXML appends this new volume to the list as
well.

Fix that by passing a new volume definition to
virStorageBackendZFSParseVol so it could determine if it needs to add
this volume to the list.

In qemuDomainSnapshotCreateDiskActive() if we jumped to cleanup from a
failed actions = virJSONValueNewArray(), then 'cfg' would be NULL.

So just return -1, which in turn removes the need for cleanup:

Coverity complained about the following:

(3) Event ptr_arith:
   Performing pointer arithmetic on "cur_fd" in expression "cur_fd++".
130             return virNetServerServiceNewFD(*cur_fd++,

The complaint is that pointer arithmetic taking place instead of the
expected auto increment of the variable...  Adding some well placed
parentheses ensures our order of operation.

For virtio-blk-pci disks with the disk iothread attribute that are
running the correct emulator, add the "iothread=iothread#" to the
-device command line in order to enable iothreads for the disk as
long as the command is available, the disk iothread value provided is
valid, and is supported for the disk device being added

Add a new disk "driver" attribute "iothread" to be parsed as the thread
number for the disk to use. In order to more easily facilitate the usage
and configuration of the iothread, a "zero" for the attribute indicates
iothreads are not supported for the device and a positive value indicates
the specific thread to try and use.

Add a new capability to ensure the iothreads feature exists for the qemu
emulator being run - requires the "query-iothreads" QMP command. Using the
domain XML add correspoding command argument in order to generate the
threads. The iothreads will use a name space "iothread#" where, the
future patch to add support for using an iothread to a disk definition to
merely define which of the available threads to use.

Add tests to ensure the xml/argv processing is correct.  Note that no
change was made to qemuargv2xmltest.c as processing the -object element
would require knowing more than just iothreads.

Introduce XML to allowing adding iothreads to the domain. These can be
used by virtio-blk-pci devices in order to assign a specific thread to
handle the workload for the device.  The iothreads are the official
implementation of the virtio-blk Data Plane that's been in tech preview
for QEMU.

Coverity noted that all callers to libxlDomainEventQueue() could ensure
the second parameter (event) was true before calling except this case.
As I look at the code and how events are used - it seems that prior to
generating an event for the dom == NULL condition, the resume/suspend
event should be queue'd after the virDomainSaveStatus() call which will
goto cleanup and queue the saved event anyway.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Implement the API function for virDomainListGetStats and
virConnectGetAllDomainStats in a modular way and implement the
VIR_DOMAIN_STATS_STATE group of statistics.

Although it may look like the function looks universal I'd rather not
expose it to other drivers as the coming stats groups are likely to do
qemu specific stuff to obtain the stats.

One useless warning, but the other one rather pertinent. On entry
the 'trans' variable is initialized to VIR_DOMAIN_DISK_TRANS_DEFAULT.
When the "trans" was found in the parsing loop it def->geometry.trans
was assigned to the return from virDomainDiskGeometryTransTypeFromString
and then 'trans' was used to do the comparison to see if it was valid.

So remove 'trans' and use def->geometry.trans properly

A bunch of false positives brought on by our own doings

A bunch of a useless warnings brought on by our own doing.

The PROBE macro can expand to more than one line/statement - put curly
braces around the if statement to be safe

If there was a failure processing 'authdef' and the code went to cleanup
before the setting to source->auth, then it'd be leaked.

Coverity found that the 'buf' wasn't VIR_FREE'd at exit.

Coverity determines that when jumping to the connected: label, the
addressinfo (ai) is not free'd.

In libxlDomainMigrationPrepare() if the uri_in is false, then
'hostname' is allocated and used "generically" in the routine,
but not freed.  Conversely, if uri_in is true, then a uri is
allocated and hostname is set to the uri->hostname value and
likewise generically used.

At function exit, hostname wasn't free'd in the !uri_in path,
so that was added.  To just make it clearer on usage the else
path became the call to virURIFree() although I suppose technically
it didn't have to since it would be a call using (NULL)

In the error path the 'ipaddr' wasn't VIR_FREE'd before jumping to cleanup

Need to free 'xmlFromFile' on/for the error path when current was
returning false only

Need to VIR_FREE the startip/endip we allocated for the error message

Coverity determined that on error path that 'mach' wouldn't be free'd
Since virCapabilitiesFreeGuestMachine() isn't globally available, we'll
insert first and then if the VIR_STRDUP's fail they it will eventually
cause the 'mach' to be freed in the error path

On the error path need to free the chrdef

Coverity found that on error paths, the 'arg' value wasn't be cleaned
up. Followed the example in qemuAgentSetVCPUs() where upon successful call
to qemuAgentCommand() the 'cpus' is set to NULL; otherwise, when cleanup
occurs the free the memory for 'arg'

In qemuParseISCSIString() if an error was returned, then the call
to qemuParseDriveURIString() where the uri is free'd wouldn't be run

Coverity determined that the copied 'oldguest' would be leaked for
both error and success paths.

Resolve a few RESOURCE_LEAK's identified by Coverity

In each of these cases, Coverity complains that the result count returned
on error paths would be -1 disregarding that the count and the corresponding
are "linked" together (it doesn't know that).  Simple enough to check and
remove the warning

Add "domstats" command that excercises both of the new APIs depending if
you specify a domain list or not. The output is printed as a key=value
list of the returned parameters.

In function virQEMUCapsParseMachineTypesStr, VIR_STRNDUP allocates
memory for 'name' in {do,while} loop. If 'name' isn't freed before
'continue', its memory will be allocated again in the next loop.
In this case the memory allocated for 'name' in privious loop is
useless and not freed. Free it before continue this loop to fix that.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

The 'lib' handle will be leaked if 'dlsym' condition fails.
So close the handle before return.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Coverity determined that 'conflict' would be leaked.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>