For a long time we've masked out VIR_DOMAIN_BLOCK_COPY_SHALLOW if
there's no backing chain for the copied disk to simplify the code.

One of the refactors of the block copy code caused that we no longer
update the 'flags' variable just the local copies. This was okay until
in ccd4228a we started storing the job flags in the block job data.

Given that we modify how we call qemu we also should modify @flags so
that the correct value is recorded in the block job data.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Move the check whether the job is already synchronised to the beginning
of the function so that we don't try to do some of the steps necessary
for pivoting prior to actually wanting to pivot.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Update to v4.2.0-2265-g67923a7ea6 to pick up recent addition of
'allow-write-only-overlay' feature of 'blockdev-snapshot' command.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The stub impl of virGetDeviceID just returns ENOSYS and does not
initialize the min/maj output parameters. This lead to a false
positive warning on mingw about possible use of uninitialized
variables.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The qemuMonitorTestNew() function returns with the monitor object
locked, and expects it to still be locked when qemuMonitorTestFree
is called.  The qemuhotplug test, however, explicitly unlocks the
monitor, but then forgets to lock it again. As a result the
qemuMonitorTestFree function is unlocking a mutex it doesn't own.

This bug has existed forever, but since we use normal POSIX mutexes
and don't check the return value of pthread_mutex_lock/unlock we
didn't see the error. It was harmless until the switch to the per
monitor event loop which requires the thread synchronization to
work reliably, whereupon it started crashing.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

According to the linked BZ, machined expects either valid
hostname or valid FQDN (see systemd commit
v239-3092-gd65652f1f2). While in case of multiple dots, a
trailing one doesn't violate FQDN, it does violate the rule in
case of something simple, like "domain.". But it's safe to remove
it in both cases.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1808499
Fixes: 45464db8Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'nfs' variable was set to -1 or -2 on agent failure. Cleanup then tried
to free 'nfs' elements of the array which resulted into a crash.

Make 'nfs' size_t and assign it only on successful agent call.

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

Broken by commit 599ae372Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The only caller doesn't check the value and also there are no real
errors to report anyways.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The virQEMUCaps structure has usedQMP member which in the past
used to tell if qemu we are dealing with is capable of QMP. Well,
we don't support HMP anymore (minus a few HMP passthrough
commands, which are wrapped into QMP anyways) and the member is
not used really.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

needReply added in [1] looks redundant. Indeed it is set to false only
when mon->await_event is set too (the only exception qemuAgentFSTrim
which is mistaken).

However it fixes the issue when qemuAgentCommand exits on error path and
mon->await_event is not reset. Let's instead reset mon->await_event properly.

Also remove "Woken up by event" debug message as it can be misleading.
We can get it also if monitor is closed due to serial changed event
currently. Anyway both qemuAgentClose and qemuAgentNotifyEvent log
itself.

[1] qemu: make sure agent returns error when required data are missing
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Sync was introduced in [1] to check for ga presence. This
check is racy but in the era before serial events are available
there was not better solution I guess.

In case we have the events the sync function is different. It allows us
to flush stateless ga channel from remnants of previous communications.
But we need to do it only once. Until we get timeout on issued command
channel state is ok.

[1] qemu_agent: Issue guest-sync prior to every command
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a disk has persistent reservations enabled, qemu-pr-helper
might open not only /dev/mapper/control but also individual
targets of the multipath device. We are already querying for them
in CGroups, but now we have to create them in the namespace too.
This was brought up in [1].

1: https://bugzilla.redhat.com/show_bug.cgi?id=1711045#c61Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NLin Ma <LMa@suse.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

This converts the QEMU agent APIs to use the per-VM
event loop, which involves switching from virEvent APIs
to GMainContext / GSource APIs.

A GSocket is used as a convenient way to create a GSource
for a socket, but is not yet used for actual I/O.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We are dealing with the QEMU agent, not the monitor.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This converts the QEMU monitor APIs to use the per-VM
event loop, which involves switching from virEvent APIs
to GMainContext / GSource APIs.

A GSocket is used as a convenient way to create a GSource
for a socket, but is not yet used for actual I/O.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Tests which are using the QEMU monitor / agent need to have an
event thread running a private GMainContext.

There is already a thread running the main libvirt event loop
but this can't be eliminated yet as it is used for more than
just the monitor client I/O.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

In common with regular QEMU guests, the QMP probing
will need an event loop for handling monitor I/O
operations.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The event loop thread will be responsible for handling
any per-domain I/O operations, most notably the QEMU
monitor and agent sockets.

We start this event loop when launching QEMU, but stopping
the event loop is a little more complicated. The obvious
idea is to stop it in qemuProcessStop(), but if we do that
we risk loosing the final events from the QEMU monitor, as
they might not have been read by the event thread at the
time we tell the thread to stop.

The solution is to delay shutdown of the event thread until
we have seen EOF from the QEMU monitor, and thus we know
there are no further events to process.

Note that this assumes that we don't have events to process
from the QEMU agent.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We want a way to easily run a private GMainContext in a
thread, with correct synchronization between startup
and shutdown of the thread.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virbpf module wraps syscalls to BPF. However, if the kernel
headers used at the compile time don't have support for BPF the
module offers stubs which return a negative one to signal error
to the caller. But there is a slight discrepancy between real
functions and these stubs. While the former set errno and return
-1 the latter report an error (without setting the errno) and
return -1. This is not optimal because the caller might see stale
errno and overwrite the error message with a less accurate one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

In the virCgroupV2DevicesAvailable() function we try to determine
whether CGroups version 2 are available. We do this by opening
what we believe is the CGroup mount point and issuing a BPF call.
When the call fails, a debug message is printed. However, the BPF
call sets errno too. Include it in the debug message to help us
with debugging.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

When rewriting the virDomainDiskTranslateSourcePool() function in
v6.1.0-rc1~184 a typo was introduced. Previously, we allowed
startup policy only for those volumes which translated to
VIR_STORAGE_TYPE_FILE. But starting with the referenced commit,
the value we checked for was changed to VIR_STORAGE_VOL_FILE
which comes from a different enum and has a different value too.
This is wrong, because virStorageSourceGetActualType() returns a
value from the original enum.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1811728Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Use g_autoptr for the virCPUDef variables.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Use g_autoptr for the virCPUDef variables and get rid
of the cleanup label.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Use an autofree'd helper variable to store the socket path
and free it after the function finishes.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Fixes: 5b8569ddReviewed-by: NMichal Privoznik <mprivozn@redhat.com>

virCPUDefPtr uses refcounting internally and must be allocated
using virCPUDefNew, otherwise virCPUDefFree would be a no-op.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Fixes: fa2404bf
Fixes: eee09435Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Free the x86_64 schema before overwriting it with s390x schema.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Fixes: eee09435Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Add /usr/bin/* to -trace-children-skip
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When a type is registered, it holds allocated memory until
the program exits.

Add an exception to valgrind.supp to make the output of
  make -C tests valgrind
more readable.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When preparing images for block jobs we modify their seclabels so
that QEMU can open them. However, as mentioned in the previous
commit, secdrivers base some it their decisions whether the image
they are working on is top of of the backing chain. Fortunately,
in places where we call secdrivers we know this and the
information can be passed to secdrivers.

The problem is the following: after the first blockcommit from
the base to one of the parents the XATTRs on the base image are
not cleared and therefore the second attempt to do another
blockcommit fails. This is caused by blockcommit code calling
qemuSecuritySetImageLabel() over the base image, possibly
multiple times (to ensure RW/RO access). A naive fix would be to
call the restore function. But this is not possible, because that
would deny QEMU the access to the base image.  Fortunately, we
can use the fact that seclabels are remembered only for the top
of the backing chain and not for the rest of the backing chain.
And thanks to the previous commit we can tell secdrivers which
images are top of the backing chain.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1803551Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Our decision whether to remember seclabel for a disk image
depends on a few factors. If the image is readonly or shared or
not the chain top the remembering is suppressed for the image.
However, the virSecurityManagerSetImageLabel() is too low level
to determine whether passed @src is chain top or not. Even though
the function has the @parent argument it does not necessarily
reflect the chain top - it only points to the top level image in
the chain we want to relabel and not to the topmost image of the
whole chain. And this can't be derived from the passed domain
definition reliably neither - in some cases (like snapshots or
block copy) the @src is added to the definition only after the
operation succeeded. Therefore, introduce a flag which callers
can use to help us with the decision.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

If only IPv6 is configured on the host, getaddrinfo with AI_ADDRCONFIG
in hints would return EAI_ADDRFAMILY for nodenames that resolve to IPv4.

Also pass AI_V4MAPPED to accept IPv4-mapped addresses on IPv6-only
systems.
Signed-off-by: NZhimin Feng <fengzhimin1@huawei.com>
[rewrote the commit message - jtomko]
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This is the same timeout of all other daemons, and just like them
virtlogd is socket-activated, so it will automatically be started
on demand whenever that's necessary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

In the following recent change:

  commit db728663
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Tue Jan 14 10:40:52 2020 +0000

    util: add API for reading password from the console

the fact that "bufptr" pointer may point to either heap or stack
allocated data was overlooked. As a result, when the strdup was
removed, we ended up returning a pointer to the local stack to
the caller. When the caller referenced this stack pointer they
got out garbage which fairly quickly resulted in a crash.

We need to copy the stack buffer into heap memory in the username
case.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Virtualization event types were added in 2.0.5:
https://github.com/linux-audit/audit-userspace/commit/3755e9ff

Even Ubuntu 14.04 (which we don't support) has 2.3.2.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

When spawning a thread via our virThread APIs we let pthread
spawn this helper thread which sets couple of thread local
variables (e.g. thread job name or thread worker name) and as of
v6.1.0-40-gc85256b3 it also sets pthread name (which is then
visible in `ps' output for instance). Only after these steps the
intended function is called. However, just before calling it we
free the buffer that holds the thread name which results in
invalid memory reads:

==47027== Invalid read of size 1
==47027==    at 0x48389C2: strlen (vg_replace_strmem.c:459)
==47027==    by 0x58BB3D6: __vfprintf_internal (vfprintf-internal.c:1645)
==47027==    by 0x58CE6E0: __vasprintf_internal (vasprintf.c:57)
==47027==    by 0x574BA28: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.6000.7)
==47027==    by 0x57240CC: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.6000.7)
==47027==    by 0x48E0EFA: vir_g_strdup_vprintf (glibcompat.c:209)
==47027==    by 0x493AA05: virLogVMessage (virlog.c:573)
==47027==    by 0x493A8FE: virLogMessage (virlog.c:513)
==47027==    by 0x4992FC7: virThreadJobClear (virthreadjob.c:121)
==47027==    by 0x4992844: virThreadHelper (virthread.c:237)
==47027==    by 0x5817496: start_thread (pthread_create.c:486)
==47027==    by 0x59563CE: clone (clone.S:95)

The problem is that neither virThreadJobSetWorker() nor
virThreadJobSet() create a copy of passed name. They just set a
thread local variable to point to the buffer which is then
freed. Moving the free towards the end of the wrapper function
solves the issue.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The 'auths' struct in the test driver was not free()d. This was easy to
miss because the default XML doesn't include auth info.
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

'template' might be used uninitialized.

Use g_autofree for everything and remove all the custom labels.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>