Turns out that it's not enough to pass the qemu:///embed root to
virQEMUDriverConfigNew(), you also have to make sure the same
string is copied into the virQEMUDriver structure yourself, and
not doing so in our case resulted in the cleanup never happening
and in distcheck failing because of that.

On the other hand, actually setting config->embeddedRoot would
result in different paths being generated for each test run, which
would obviously break qemuxml2argvtest, so that's not an option
either.

This reverts commit d98cc196.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Now that the QEMU driver natively supports storing all its runtime
data inside an arbitrary directory, we can avoid having multiple
copies of the same logic in the test suite.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

To attempt to catch unit tests which accidentally create files in $HOME,
or $XDG_RUNTIME_DIR, poison these env vars by pointing them to
directories which don't exist. This should give easier to debug test
failures. For example:

$ VIR_TEST_DEBUG=1 ./qemuhotplugtest
Could not initialize HostdevManager - operation failed: Failed to create state dir '/bad-test-used-env-xdg-runtime-dir/libvirt/hostdevmgr'
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Fix win32 keycode for VK_OEM_102
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We need to prevent accidental deletion of release tags and maint
branches.

We need to ensure that shared CI runners are enabled on all repos.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We need this for all tests that use virHostdevManager, because
during creation of this object for unprivileged connections
like those used in the test suite we would end up writing inside
the user's home directory.

That's bad manners in general, but when running the test suite
inside a purposefully constrained environment such as the one
exposed by pbuilder, it turns into an outright test failure:

  Could not initialize HostdevManager - operation failed: Failed
  to create state dir '/nonexistent/.cache/libvirt/hostdevmgr'
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The churn in the output files is caused primarily by the fact that
blockdev support has been introduced.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The churn in the output files is caused primarily by the fact that
replies were generated on a POWER9 machine, which is good because
we didn't have coverage of that before.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

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

So that we don't have to chase frequent Fedora releases, move the
non-build related jobs onto the long life CentOS 8 distro.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently, qemucapsprobe fails when libvirt is not already installed
on the system:

  $ ./tests/qemucapsprobe /path/to/qemu-system-ppc64 >/dev/null
  I/O warning : failed to load external entity "/usr/share/libvirt/cpu_map/index.xml"
  2020-05-06 09:49:59.136+0000: 269822: info : libvirt version: 6.4.0
  2020-05-06 09:49:59.136+0000: 269822: info : hostname: [...]
  2020-05-06 09:49:59.136+0000: 269822: warning : virQEMUCapsLogProbeFailure:5127 :
  Failed to probe capabilities for /path/to/qemu-system-ppc64: XML error: failed to
  parse xml document '/usr/share/libvirt/cpu_map/index.xml'

It would be great if the tool could work entirely out of the build
directory, and this patch achieves just that.
Suggested-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

We never supported host-model CPUs on ARM and we don't want to support
them even once patches for direct detection of host CPU are merged. And
since using host CPU definition for host-model CPUs exists only for
backward compatibility, we should not use it for any host-model support
added in the future. Such enhancement should exclusively use the result
of query-cpu-model-expansion. Until proper host-model support is
implemented for ARM (if ever), we need to make sure the detected host
CPU is not accidentally used for host-model CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Start the new capability file for the new development cycle of QEMU.

Note that compared to previous version this was generated on an AMD cpu.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When a system has enabled the iptables/ip6tables services rather than
firewalld, there is no explicit ordering of the start of those
services vs. libvirtd. This creates a problem when libvirtd.service is
started before ip[6]tables, as the latter, when it finally is started,
will remove all of the iptables rules that had previously been added
by libvirt, including the custom chains where libvirt's rules are
kept. This results in an error message similar to the following when a
user subsequently tries to start a new libvirt network:

 "Error while activating network: Call to virNetworkCreate failed:
 internal error: Failed to apply firewall rules
 /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \
   --in-interface virbr2 --jump REJECT:
 ip6tables: No chain/target/match by that name."

(Prior to logging this error, it also would have caused failure to
forward (or block) traffic in some cases, e.g. for guests on a NATed
network, since libvirt's rules to forward/block had all been deleted
and libvirt didn't know about it, so it couldn't fix the problem)

When this happens, the problem can be remedied by simply restarting
libvirtd.service (which has the side-effect of reloading all
libvirt-generated firewall rules)

Instead, we can just explicitly stating in the libvirtd.service file
that libvirtd.service should start after ip6tables.service and
ip6tables.service, eliminating the race condition that leads to the
error.

There is also nothing (that I can see) in the systemd .service files
to guarantee that firewalld.service will be started (if enabled) prior
to libvirtd.service. The same error scenario given above would occur
if libvirtd.service started before firewalld.service.  Even before
that, though libvirtd would have detected that firewalld.service was
disabled, and then turn off all firewalld support. So, for example,
firewalld's libvirt zone wouldn't be used, and most likely traffic
from guests would therefore be blocked (all with no external
indication of the source of the problem other than a debug-level log
when libvirtd was started saying that firewalld wasn't in use); also
libvirtd wouldn't notice when firewalld reloaded its rules (which also
simultaneously deletes all of libvirt's rules).

I'm not aware of any reports that have been traced back to
libvirtd.service starting before firewalld.service, but have seen that
error reported multiple times, and also don't see an existing
dependency that would guarantee firewalld.service starts before
libvirtd.service, so it's possible it's been happening and we just
haven't gotten to the bottom of it.

This patch adds an After= line to the libvirtd.service file for each
of iptables.service, ip6tables.service, and firewalld.servicee, which
should guarantee that libvirtd.service isn't started until systemd has
started whichever of the others is enabled.

This race was diagnosed, and patch proposed, by Jason Montleon in
https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb
agreed with him that this change to libvirtd.service was a reasonable
thing to do, but I guess everyone thought someone else was going to
post a patch, so in the end nobody did.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

To make it simpler to answer questions of "Why doesn't this thing work
for me?"
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

In formatdomain, using 'libxl' and 'xen' is redundant since they now
both refer to the same driver. 'xen' predates 'libxl' and unambiguously
identifies the Xen hypervisor, so drop the use of 'libxl'.

In aclpolkit, the connection URI was erroneously identified as 'libxl'
and the name 'xenlight'. Change the URI to 'xen' and driver name to 'Xen'.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The libxl driver has suffered an identity crisis since its introduction.
It took on the name 'libxl' since at the time libvirt already contained
a 'xen' driver for the old Xen toolstack implementation. 'libxl' is short
for libxenlight, which is often called xenlight. Unfortunately all forms
of the name are used in the libxl driver.

The only remaining use of the 'xenlight' form is when interacting with
the host device manager, which is difficult to change since it would
cause problems when upgrading the driver.

Rename the #define to make it clear the 'xenlight' form is internal and
add a comment describing why the name exists and that its use should be
discouraged.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The libxl driver declares its name as 'Xen' through the public
virConnectGetType() API. In the virHypervisorDriver table the name is
set to 'xenlight'. To add more confusion, the name is set to 'LIBXL'
in the virStateDriver. For consistency, use the same name in the driver
tables as reported in the public virConnectGetType() API.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The virConnectGetType() returns "Xen" for libxl, not "LIBXL".

This prevents users opening a connection to the libxl driver when using
the modular daemons.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This partially reverts fe65e9c8.

In the referenced commit I removed @ret from
virHostValidateBhyve() thinking it wasn't used when in fact it is
- it's usage is hidden under MODULE_STATUS_WARN(). Reintroduce
the variable back.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

In a few places we use 0 and false, or 1 and true interchangeably
even though the variable or return type in question is boolean.
Fix those places.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There are few places where a return variable is introduced (ret
or retval), but then is never changed and is then passed to
return. Well, we can return the value that the variable is
initialized to directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There are few functions that currently return an integer but in
fact they always return the same integer (zero). Make them void.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since it's introduction in v0.9.7-147-gf4324e32 the
virNetServerClientInitKeepAlive() function returned nothing than
a negative one. Fortunately, this did not pose any problem
because we ignored the retval happily. Well, it's time to check
for the retval because the function might fail regularly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Instead of the following pattern:

  type ret;
  ...
  ret = func();
  return ret;

we can use:

  return func()

directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

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

Debian always runs autoreconf at package build time, which means
that apt-get build-dep will bring in everything that's needed to
build libvirt from a git clone; Fedora and RHEL, however, skip
this step, so we have to install some extra packages manually.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This is the proper way to do it according to our reStructuredText
style guidelines.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Replace Fedora 30 with Fedora 32
Replace Ubuntu 16.04 with Ubuntu 20.04
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This removes the locally maintained DCO checking script in favour of the
shared container image provided by libvirt-ci.git.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

After the commit dc0771cf, ret variable no longer
represents the status of the return code, use
data->ret replace it.
Signed-off-by: NXu Yandong <xuyandong2@huawei.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

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

"allows to" -> "allows one to"

Spotted by Lintian (spelling-error-in-manpage tag).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

In the past we added 1024 bytes of padding to saved state images so that
users can run "virsh managedsave-edit $GUEST" and make XML changes which
increase the size of the XML document. This padding was accidentally
lost a while back

  commit 6b9b21db
  Author: Peter Krempa <pkrempa@redhat.com>
  Date:   Wed Feb 17 13:10:11 2016 +0100

    qemu: Remove unnecessary calculations in qemuDomainSaveMemory

The original 1024 bytes was unreasonably stingy when we consider that
the QEMU state is typically going to be many 100's of MB in size. Thus
this adds 64 KB of padding after the XML which should cope with any
plausible modifications a user will want to make.

  https://bugzilla.redhat.com/show_bug.cgi?id=1229255Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NTobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Only probe QEMU binary with accel=tcg if TCG is not disabled.
Similarly, only add a VIR_DOMAIN_VIRT_QEMU guest if TCG
is available.
Signed-off-by: NTobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since QEMU 2.10 it is possible to disable TCG when building
QEMU. Introduce a capability that reflects this.
Signed-off-by: NTobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Now that qemuBuildVirtioOptionsStr can not fail anymore, remove its
return value and make it void.
Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>