If we are certain that the checkpoint creation failed we remove the
metadata from the list. To allow reusing this in the backup code add a
new helper and export it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Document that --diskspec DISK,snapshot=no disables snapshot for the
given disk.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Introduced in QEMU by commit v4.1.0-266-g80db491da4.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When allowing/denying a device in devices CGroupV2 we have to
write a BPF program for it. The program we put there is merely
static and all it does it looks up a device in a hash table (also
known as map in BPF terminology). A map is referenced via an FD
which can be acquired via virBPFCreateMap() and like any other FD
it should be closed when no longer needed. However, we close it
twice: the first time in virCgroupV2DevicesAttachProg() which
closes it unconditionally, and the second time in either
virCgroupV2DevicesCreateProg() or
virCgroupV2DevicesPrepareProg(). Remove the second close.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This function is not called outside of the source file where it's
defined. There's no need to export it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Any static list of images is destined to become outdated eventually,
so let's start generating it dynamically instead.

Unfortunately there doesn't seem to be a straightforward way to get
Podman/Docker to list all repositories under quay.io/libvirt, so we
have to resort to searching and filtering manually; and since the
two tools behave slightly differently in that regard, it's more
sane to have the logic in a separate shell script than it would be
to keep it inline in the Makefile with all the annoying escaping
doing so would entail.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

Introduce an option '--memory' for showing memory related
information. The memory bandwidth infomatio is listed as:

Domain: 'libvirt-vm'
 memory.bandwidth.monitor.count=4
 memory.bandwidth.monitor.0.name=vcpus_0-4
 memory.bandwidth.monitor.0.vcpus=0-4
 memory.bandwidth.monitor.0.node.count=2
 memory.bandwidth.monitor.0.node.0.id=0
 memory.bandwidth.monitor.0.node.0.bytes.total=10208067584
 memory.bandwidth.monitor.0.node.0.bytes.local=4807114752
 memory.bandwidth.monitor.0.node.1.id=1
 memory.bandwidth.monitor.0.node.1.bytes.total=8693735424
 memory.bandwidth.monitor.0.node.1.bytes.local=5850161152
 memory.bandwidth.monitor.1.name=vcpus_7
 memory.bandwidth.monitor.1.vcpus=7
 memory.bandwidth.monitor.1.node.count=2
 memory.bandwidth.monitor.1.node.0.id=0
 memory.bandwidth.monitor.1.node.0.bytes.total=853811200
 memory.bandwidth.monitor.1.node.0.bytes.local=290701312
 memory.bandwidth.monitor.1.node.1.id=1
 memory.bandwidth.monitor.1.node.1.bytes.total=406044672
 memory.bandwidth.monitor.1.node.1.bytes.local=229425152
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>

The underlying resctrl monitoring is actually using 64 bit counters,
not the 32bit one. Correct this by using 64bit data type for reading
hardware value.

To keep the interface consistent, the result of CPU last level cache
that occupied by vcpu processors of specific restrl monitor group is
still reported with a truncated 32bit data type. because, in silicon
world, CPU cache size will never exceed 4GB.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

One of the first versions thought of using disk path as the second
option but this was dropped as being a legacy interface. Remove the
leftover pointless <choice> wrapper for the disk name as there's just
one option now.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Commit d75f865f caused a job-deadlock if
a VM is running the backup job and being destroyed as it removed the
cleanup of the async job type and there was nothing to clean up the
backup job.

Add an explicit cleanup of the backup job when destroying a VM.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

When cancelling the blockjobs as part of failed backup job startup
recover we didn't pass in the correct async job type. Luckily the block
job handler and cancellation code paths use no block job at all
currently so those were correct.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Now that we delete the images elsewhere it's not required. Additionally
it's safe to do as we never released an upstream version which required
this being in place.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

While qemu is running both locations are identical in semantics, but the
move will allow us to fix the scenario when the VM is destroyed or
crashes where we'd leak the images.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

In contrast to snapshots the backup job does not complain when the
backup job's store file has backing pre-configured. It's actually
required so that the NBD server exposes all the data properly.

Remove our fake termination and use the existing disk source as backing.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

qemuDomainObjPrivateDataClear clears state which become invalid after VM
stopped running and the node name allocator belongs there.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The waiting loop used QEMU_ASYNC_JOB_NONE rather than 'asyncJob' passed
from the caller.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a comment against each gnulib module suggesting strategy
for replacement.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

* canonicalize-lgpl: replaced by realpath()/g_canonicalize_filename()
* clock-gettime: replaced by g_get_(real|monotonic)_time
* dirname-lgpl: replaced by g_path_get_dirname()
* fclose: we aren't affected by any portability problems it fixes
* fdatasync: every platform we call fdatasync on has it present
* fsync: replaced by g_fsync()
* fnmatch: replaced by g_pattern_match()
* getcwd-lgpl: replaced by g_get_current_dir()
* gethostname: replaced by g_get_hostname()
* gettimeofday: replaced by g_get_(real|monotonic)_time
* setenv: replaced by g_setenv()
* strptime: replaced by GDateTime
* timegm: replaced by GDateTime
* unsetenv: replaced by g_unsetenv()
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

All places where we use strptime/timegm()/mktime() are handling
conversion of dates in a format compatible with ISO 8601, so we
can use the GDateTime APIs to simplify code.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

g_networking_init() does the same as our custom code.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Note the glib function returns a const string because it
caches the hostname using a one time thread initializer
function.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The canonicalize_file_name(path) is equivalent to calling
realpath(path, NULL). Passing NULL for the second arg of
realpath is not standardized behaviour, however, Linux,
FreeBSD > 6.4 and macOS > 10.5 all support this critical
extension.

This leaves Windows which doesn't provide realpath at all.
The g_canonicalize_filename() function doesn't expand
symlinks, so is not strictly equivalent to realpath()
but is close enough for our Windows portability needs
right now.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

commandhelper.c is not converted since this is a standalone
program only run on UNIX, so can rely on getcwd().
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

A few places were importing dirname.h without actually using it.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The last_component() method is a GNULIB custom function
that returns a pointer to the base name in the path.
This is similar to g_path_get_basename() but without the
malloc. The extra malloc is no trouble for libvirt's
needs so we can use g_path_get_basename().
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

g_get_real_time() returns the time since epoch in microseconds.
It uses gettimeofday() internally while libvirt used clock_gettime
because it is declared async signal safe. In practice gettimeofday
is also async signal safe *provided* the timezone parameter is
NULL. This is indeed the case in g_get_real_time().
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The g_pattern_match function_simple is an acceptably close
approximation of fnmatch for libvirt's needs.

In contrast to fnmatch(), the '/' character can be matched
by the wildcards, there are no '[...]' character ranges and
'*' and '?' can not be escaped to include them literally in
a pattern.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The GLib g_lstat() function provides a portable impl for
Win32.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

A wrapper that calls g_fsync on Win32/macOS and fdatasync
elsewhere. g_fsync is a stronger flush than we need but it
satisfies the caller's requirements & matches the approach
gnulib takes.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The g_fsync() API provides the same Windows portability
as GNULIB does for fsync().
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

g_fsync isn't available until 2.63 so we need a compat
wrapper temporarily.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Eliminate direct use of normal setenv/unsetenv calls in
favour of GLib's wrapper. This eliminates two gnulib
modules
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The gstdio.h header defines some low level wrappers for
things like fsync, stat, lstat, etc.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When using GNULIB with Winsock, libvirt will never see the normal HANDLE
objects, instead GNULIB guarantees that libvirt gets a C runtime file
descriptor. The GNULIB poll impl also expects to get C runtime file
descriptors rather than HANDLE objects. Document this behaviour so that
it is clear to applications providing event loop implementations if they
need Windows portability.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Ideally we would test macOS 10.15 as the newest release, however, that
is not available in Travis yet. We can at least test newer XCode
versions though to get toolchain validation.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We initially claimed to only support the most recent macOS
release, which is currently 10.15. Our Travis CI, however,
is validating 10.14.4 / XCode 10.3.

For almost all of our other platforms, we support multiple
releases to some degree. This change brings macOS in line
with other long life distros, covering the most recent &
most recent but one for a 2 year overlap. With this docs
change our CI is now actually testing our minimum version.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We have a strong check for GCC >= 4.8, but don't validate any
version number for CLang historically.

This defines the min CLang to be 3.4 which is what is available
for RHEL-7. macOS uses a different versioning scheme for CLang,
based off XCode versions. There is a mapping recorded at

  https://en.wikipedia.org/wiki/Xcode#Toolchain_versions

Here we see upstream CLang 3.4 corresponds to XCode 5.1

XCode 5.1 is available for macOS 10.8.4 or later which
trivially satisfies our platform support matrix requirements.

All these versions match what QEMU declares for its min GCC
and CLang checks.
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>