The files no longer exist, at least not in their previous form,
so references to them need to be reworked to still make sense.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This file contains the old school ChangeLog, which was manually
updated for every set of changes before the switch to git.

When libvirt was imported into git, however, *all* history was
preserved, including the changes documented in this file, and
can still be inspected using 'git log' just like more recent
changes: the format might be slightly different, but that's not
quite reason enough to treat this file any differently than the
git-generated ChangeLog we just dropped.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Our ChangeLog is generated by basically redirecting the output
of 'git log' into it so, as can be expected, it has only gotten
bigger as development has progressed. As of today, its size has
reached pretty much comical levels:

  $ du -sk ChangeLog
  11328 ChangeLog

All of that for information *literally nobody* cares about: end
users and distro maintainers have proper release notes lovingly
compiled for them, while developers peruse the history either by
calling 'git log' directly or through their favorite $EDITOR's
git integration.

Replacing the generated ChangeLog with a short message pointing
interested parties to the git repository does not only reduce
the size of the unpacked sources from 259904 KiB to 248576 KiB
(~4% saving): from a quick test on my laptop, doing so reduces
the size of the *compressed* release archive from 15140 KiB to
12364 KiB (~18% saving) and also takes the time needed to run
'make distcheck' down from 4:44 to 4:21 (~8% saving).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

* docs/news.xml: updated for release date
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Add hppa, nios2, or1k, riscv32 and riscv64 to the profile.

Fixes: https://bugs.debian.org/914940Signed-off-by: Nintrigeri <intrigeri@boum.org>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The VM Manager app is no longer present on the Play store and while
Google shows a couple of hits they look like the typical untrustworthy
3rd party download redistributors rather than an official site.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The page we link to is a 404 and github repo hasn't been touched since
2012 so is clearly dead.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The libvirt specific page linked for buildbot is a 404. This replacement
link is the closest to what was originally linked.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The project website http://archipelproject.org/ is dead, reporting a
cloudflare error message

The git repo at https://github.com/ArchipelProject/Archipel/ hasn't
had a commit since Nov 2016, and the last release was a beta6 release
in 2013.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

Update the wording to note the values for polling are purely dynamic
and won't be saved across domain stop/(re)start or save/restore.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Check that the attribute is the same in qemuDomainDiskChangeSupported
in case somebody tries to change it using the UpdateDevice API.

https://bugzilla.redhat.com/show_bug.cgi?id=1601677Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

A macro for comparing string fields of the disk.

https://bugzilla.redhat.com/show_bug.cgi?id=1601677Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

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

This reverts commit 047cfb05
Using numeric comparison on strings means we reject every update
that does include the group name, even if it's unchanged.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Most of our completers used the pattern:
if ((nITEM = virITEMListAll()) < 0)
    return NULL;

but the virDomainSnapshot and virStorageVolume completers were instead
using goto error. If the ListAll fails with -1, the cleanup label was
running a loop of 'size_t i < int nITEM', which is an extreme waste of
CPU cycles. Broken since their introduction in v4.1.

Fixes: f81f8b62
Fixes: 4cb4b649Reported-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Even though Coverity can prove that 'last' is always set if the prior
loop executed, gcc 8.0.1 cannot:

  CC       conf/libvirt_conf_la-virdomainmomentobjlist.lo
../../src/conf/virdomainmomentobjlist.c: In function 'virDomainMomentMoveChildren':
../../src/conf/virdomainmomentobjlist.c:178:19: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         last->sibling = to->first_child;
         ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~

Rewrite the loop to a form that should be easier for static analysis
to work with.

Fixes: ced0898fReported-by: NBjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

commit edaf1356 modified the stats retrieval for OVS interfaces to
not fail when one of the fields was unrecognized by the ovs-vsctl
command, but ovs-vsctl was still returning an error, and libvirt was
cluttering the logs with these inconsequential error messages.

This patch modifies the GET_STAT macro to add "--if-exists" to the
ovs-vsctl command, which causes it to return an empty string (and exit
with success) if the requested statistic isn't in its database, thus
eliminating the ugly error messages from the log.

Resolves: https://bugzilla.redhat.com/1683175Signed-off-by: NLaine Stump <laine@laine.org>

The warning is reported at a code path which already reports a proper
error so it's pointless to add yet another line into logs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Avoid the extra parameter passing in the disk 'dst' parameter to be
reported instead of the device alias. Using 'dst' instead of alias does
not add much value.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

qemuDomainRemoveDiskDevice calls qemuDomainReleaseDeviceAddress which
already calls virDomainUSBAddressRelease so we don't need to call it
again.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Introduced in fdf6c89e, this dependency looks weird. It was
needed because of the way that while() loop was written - it
fetches next argument in every iteration. Therefore, our only
option was for ARG_END to have the same value as QEMU_CAPS_LAST.
This also meant that QEMU_CAPS_* could have been only at the end
of the __VA_ARGS__.

This commit reworks the while() loop and removes the dependency.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There is one specific caller (testInfoSetArgs() in
qemuxml2argvtest.c) which expect the va_list argument to change
after returning from the virQEMUCapsSetVAList() function.
However, since we are passing plain va_list this is not
guaranteed. The man page of stdarg(3) says:

  If ap is passed to a function that uses va_arg(ap,type), then
  the value of ap is undefined after the return of that function.

(ap is a variable of type va_list)

I've seen this in action in fact: on i686 the qemuxml2argvtest
fails on the second test case because testInfoSetArgs() sees
ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the
capabilities (in this case there's just one
QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not
reflected in the caller, in the next iteration testInfoSetArgs()
sees the QEMU capability and not ARG_END.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The mock fopen() function will abort if "/proc/mounts" is
requested with "r" permissions and VIR_CGROUP_MOCK_FILENAME
env var is not set.

Unfortunately this is triggering by the libselinux library
constructor when it tries to read /proc/mounts to find out
if selinuxfs is mounted in an unusual place.

This, however, only affects libselinux in Debian as that
opens with "r", while in Fedora / RHEL it opens "re" and
thus luckily never triggered the abort(), instead getting
an EACCESS.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 6b90a847.

It turns out gcc -O2 is not happy with it, complaining:

/home/pipo/libvirt/src/qemu/qemu_driver.c: In function 'qemuDomainSnapshotCreateXML':
/home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference]
     bool memory = snapdef->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL;
                   ~~~~~~~^~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference]
In file included from /home/pipo/libvirt/src/util/virbuffer.h:27,
                 from /home/pipo/libvirt/src/conf/capabilities.h:27,
                 from /home/pipo/libvirt/src/conf/domain_conf.h:32,
                 from /home/pipo/libvirt/src/qemu/qemu_agent.h:26,
                 from /home/pipo/libvirt/src/qemu/qemu_driver.c:40:
/home/pipo/libvirt/src/util/viralloc.h:125:34: error: potential null pointer dereference [-Werror=null-dereference]
 # define VIR_ALLOC_N(ptr, count) virAllocN(&(ptr), sizeof(*(ptr)), (count), true, \
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                            VIR_FROM_THIS, __FILE__, __FUNCTION__, __LINE__)
                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15103:9: note: in expansion of macro 'VIR_ALLOC_N'
     if (VIR_ALLOC_N(ret, snapdef->ndisks) < 0)
         ^~~~~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15798:45: error: null pointer dereference [-Werror=null-dereference]
             virDomainSnapshotObjGetDef(snap)->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL) {
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~

As the patch simplified one or two callers at the risk of making
many other callers now candidates to trigger aggressive compiler
warnings, it isn't worth it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use the common base class virDomainMoment for iterator callbacks
related to snapshots from the qemu code, so that when checkpoint
operations are introduced, they can share the same callbacks.

Simplify the code for qemuDomainSnapshotCurrent by better utilizing
virDomainMoment helpers.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Doing so can simplify some callers.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The qemu driver already had a full-blown virDomainMomentObjPtr to
check against, and the test driver ought to have one since we get
better error checking that the user passed in a valid object. Removes
the need for a helper function added in commit commit 4819f54b.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

ldconfig needs to be called after installing or uninstalling
shared libraries.

For a very long time, libvirt didn't have a separate package
containing just the shared libraries, and so it shipped them
in the same one as the clients.

Since commit 70b4f0e7, however, shared libraries have been
moved from -client to their own -libs package; unfortunately,
the corresponding ldconfig calls were not moved at the same
time, which is what this commit takes care of.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The VIR_MIGRATE_PARALLEL flag is implemented using QEMU's multifd
migration capability and the corresponding multifd-channels migration
parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This patch adds a new VIR_MIGRATE_PARALLEL flag for migration APIs which
will ask the hypervisor to use multiple parallel connections for
migrating a domain. The number of parallel connections can be set using
VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS typed parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Prepare for introducing a bunch of new public APIs related to
backup checkpoints by first introducing a new internal type
and errors associated with that type.  Checkpoints are modeled
heavily after virDomainSnapshotPtr (both represent a point in
time of the guest), although a snapshot exists with the intent
of rolling back to that state, while a checkpoint exists to
make it possible to create an incremental backup at a later
time.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since I was copying this text to form checkpoint XML and API
documentation, I might as well make improvements along the way. Most
of these changes are based on reviews of the checkpoint docs.

Among other things: grammar tweaks, point to a single source of
documentation rather than repeating verbosity, reword things for
easier legibility.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 86c0ed6f, and
subsequent refactorings of the function into new files.  There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also tried using it for streamlining how
the qemu driver stores snapshot state across libvirtd restarts
internally, but in the end, the risks of a new internal format
outweighed the benefits of one file per snapshot.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 1b57269c, and
subsequent refactorings of the function into new files.  There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also tried using it for streamlining how
the qemu driver stores snapshot state across libvirtd restarts
internally, but in the end, the risks of a new internal format
outweighed the benefits of one file per snapshot.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Running QEMU as root is a pretty bad idea, so try to make the
user aware of that as part of the configure summary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Our current defaults are root:wheel on FreeBSD and macOS, root:root
everywhere else.

Looking at what downstream distributions actually do, we can see that
these defaults are overriden the vast majority of the time, with a
number of variations showing up in the wild:

  * qemu:qemu -> Used by CentOS, Fedora, Gentoo, OpenSUSE, RHEL
                 and... As it turns out, our very own spec file :)

  * libvirt-qemu:libvirt-qemu -> Used by Debian.

  * libvirt-qemu:kvm -> Used by Ubuntu.

  * nobody:nobody -> Used by Arch Linux.

Based on this information, we can do a better job at integrating with
downstream packages: if the distro-specific user and group already
exist on the system then we use them, and if not (or we're building
on an unknown OS) we just use root:root as we would have before.

This change makes it less likely that people building from source
will end up running their guests as root, which is a very desiderable
outcome from the security point of view.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If qemuFirmwareFetchConfigs() returned more or fewer paths than
expected all that we see is the following error message:

  Expected 5 paths, got 7

While it is technically correct (the best kind of correct), we
can do better:

  Unexpected path (i=0). Expected /some/path got /some/other/path
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>