We lacked of HOME environment variable,
set 'HOME=/' as default.

The kernel sets up $HOME for the init process.
Therefore any init can assume that $HOME is set.
libvirt currently violates that implicit rule.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

libcap-ng >= 0.7.4 fails when it can't read /sys/kernel/cap_last_cap
and thus running a qemu guest fails.

Allow reading cap_last_cap in the libvirt-qemu apparmor abstraction.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

When FIPS mode is on, gnutls_dh_params_generate2 will fail if 1024 is
specified as the prime's number of bits, a bigger value works in both
cases.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Memory is allocated for 'mnt_src' by VIR_STRDUP in the loop. Next
loop it will be allocated again. So we need to free 'mnt_src'
before continue the loop.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Need to free 'root' and 'opts' before 'return -1' if symlink fails.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

If virSecurityManagerClearSocketLabel() fails, 'agent' won't
be freed before jumping to cleanup.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Need to free 'uri_out' on error path.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

If the condition 'ret < 0' is true, the code will jump to
'cleanup' and 'conf' won't be freed.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Coverity determined that 'log' and 'newenv' were not freed in
some cases. Free them in 'error' branch and normal branch.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Add testsuite coverage for the recent commit 0e1a1a8c.

* tests/commandhelper.c (main): Output umask.
* tests/commandtest.c (test15): Also test umask.
(mymain): Add test.
* tests/commanddata/*.log: Update expected output.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit 0e1a1a8c introduced umask for virCommand, but the variables
used emit a warning on older compilers about shadowed global
declaration.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Add umask to _virCommand, allow user to set umask to command.
Set umask(002) to qemu process to overwrite the default umask
of 022 set by many distros, so that unix sockets created for
virtio-serial has expected permissions.

Fix problem reported here:
https://sourceware.org/bugzilla/show_bug.cgi?id=13078#c11
https://bugzilla.novell.com/show_bug.cgi?id=888166

To use virtio-serial device, unix socket created for chardev with
default umask(022) has insufficient permissions.
e.g.:
-device virtio-serial \
-chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=org.fedoraproject.port.0

srwxr-xr-x 1 qemu qemu 0 21. Jul 14:19 /tmp/somefile.sock

Other users in the same group (like real user, test engines, etc)
cannot write to this socket.
Signed-off-by: NChunyan Liu <cyliu@suse.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

%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)