Commit Graph

347 Commits

Author SHA1 Message Date
Peter Krempa
56c56b3bf8 Revert "configure: Colorize output"
The colors are not based on the semantics of the message but rather
on the message itself. This means that the default human-perceived
semantics (red = bad, green = good) don't really apply and spotting a
color does not mean anythting.

This is amplified by the sheer amount of output which configure produces
and the fact that some of the messages have negative semantics or
additional output.

In case of any problem the user will have to go through everything
anyways as spotting a red or yellow line has 0 information value.

Here are a few examples:

1) some 'no' messages are not a problem:

  checking minix/config.h presence... no

2) some 'no' messages are actually positive:

  checking for special C compiler options needed for large files... no

3) in some cases a 'yes' would mean that something is broken or needs
   workaround

  checking whether stat file-mode macros are broken... no
  checking whether wint_t is too small... no
  checking whether stdint.h predates C++11... no
  checking whether the inttypes.h PRIxNN macros are broken... no
  checking whether clang gives bogus warnings for -Wdouble-promotion... no
  checking whether gettimeofday clobbers localtime buffer... no

4) due to string match based colors extra text makes messages yellow

  checking for a traditional french locale... none
  checking for working nanosleep... no (mishandles large arguments)
  checking for library containing gethostbyname... none required
  checking whether mbrtowc handles incomplete characters... (cached) guessing yes

5) in some cases the yes/no is very context dependant

  checking whether pthread_rwlock_rdlock prefers a writer to a reader... no
  checking whether this build is done by a static analysis tool... no

6) detected paths to binaries and libs are yellow despite being present

  checking for objdump... objdump
  checking for atomic ops implementation... gcc

As of the reasons above I don't think the colorization of the configure
output helps users or developers to debug the build process and
thus is not worth the extra code or output clutter.

This reverts commit c98174ce08.

ACKed-by: Michal Prívozník <mprivozn@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-09-19 14:31:15 +02:00
Peter Krempa
1a1c293ec6 Revert "virt-result.m4: Colourize summary printings"
The colorization based on the string itself makes little to no sense as
the semantic meaning of the color (red = bad, green = good) is not
extracted from the semantics of the message:

1) If there is some additional string a 'yes' is marked yellow:

configure:       driver_modules: yes (CFLAGS='' LIBS='-ldl')

2) In some cases a 'no' is actually good:

configure:                  hal: no

3) Few good/recommended configuration options are still yellow:

configure:                 QEMU: qemu:qemu

while using 'root:root' would still be yellow.

4) fields dumping config (e.g. the warning flags line) is a giant blob
  of colored text which makes little sense

configure:        Warning Flags:  -fno-common -W -Wabsolute-value
-Waddress -Waddress-of-packed-member -Waggressive-loop-optimizations
-Wall -Wattribute-warning -Wattributes -Wbad-function-cast
-Wbool-compare -Wbool-operation -Wbuiltin-declaration-mismatch
-Wbuiltin-macro-redefined -Wcannot-profile -Wcast-align
-Wcast-align=strict -Wcast-function-type -Wchar-subscripts -Wclobbered
-Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdangling-else
-Wdate-time -Wdeprecated-declarations -Wdesignated-init
-Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero
-Wdouble-promotion -Wduplicated-cond -Wduplicate-decl-speci ...

In addition if the idea is to switch to a more usable build system it
does not make sense to clutter the current one with more code.

This reverts commit 4b3ab5d213.

ACKed-by: Michal Prívozník <mprivozn@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-09-19 14:31:15 +02:00
Michal Privoznik
4b3ab5d213 virt-result.m4: Colourize summary printings
The LIBVIRT_RESULT function takes two or three arguments. The
first one is the name of the result (aka CHECK_NAME). It is
printed before the colon character. The rest of the arguments is
printed after the character. To produce colourized output a
couple of changes needs to be made.

Firstly, we need to print the CHECK_NAME using "echo -n" so that
the new line is not appended at the end of the message. To
achieve this, AS_MESSAGE_N function is introduced. It's a
verbatim copy of AS_MESSAGE (which is just another alias to
AC_MSG_NOTICE) except it doesn't put '\n' at the EOL.

The alias is defined at /usr/share/autoconf-*/autoconf/general.m4
and the AS_MESSAGE is then defined at
/usr/share/autoconf-2.69/m4sugar/m4sh.m4.

Secondly, the rest of the arguments are printed colourized and to
achieve that and also keep printing them into the log file the
_AS_ECHO and COLORIZE_RESULT functions need to be called.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-12 15:10:39 +02:00
Michal Privoznik
c98174ce08 configure: Colorize output
If we're running from a TTY we can put some colors around 'yes',
'no' and other messages.

Shamelessly copied from Ruby source code and modified a bit to
comply with syntax-check.

e487959287

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-12 15:10:26 +02:00
Michal Privoznik
9713aed1ab virt-result.m4: Align string more generously
The times, when we had small CRTs are long gone. Now, in the era
of wide screens we can be more generous when it comes to aligning
the output of configure. The longest string before the colon is
'wireshark_dissector' which counts 19 characters.  Therefore,
align the strings at 20.

At the same time, drop the useless result alignment. It behaves
oddly - it puts a space at the end of each "no" because of the
%-3s format we use.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-09-12 12:12:58 +02:00
Michal Privoznik
fe98219596 configure: Prefer LIBVIRT_RESULT over AC_MSG_NOTICE
One of the advantages is that LIBVIRT_RESULT aligns the resulting
message for us.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-09-12 12:12:54 +02:00
Marc-André Lureau
b0baafe92c qemu-conf: add configurable slirp-helper location
A slirp helper is a process that provides user-mode networking through
a unix domain socket. It is expected to follow the following
specification:
https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README.rst

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-09-06 12:47:47 +02:00
Jim Fehlig
2171442d62 xenapi: remove driver
The xenapi driver has not seen any development since its initial
contribution 9 years ago. There have been no bug reports, no patches,
and no queries about the driver on the developer or user mailing lists.
Remove the driver from the libvirt sources.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-03 15:37:54 -06:00
Andrea Bolognani
71a08c5f59 m4: Drop libxml2 version number from configure help
We don't include this information for any other library, and
having it there means there are two places we need to change
every time the required version is bumped.

configure will provide the user with a nice error message,
which includes the required version, if libxml2 found on the
system is too old.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2019-08-12 09:31:22 +02:00
Daniel P. Berrangé
e4c05240bf build: bump min libxml2 to 2.9.1
The various distros have the following libxml2 vesions:

        CentOS 7: 2.9.1
  Debian Stretch: 2.9.4
   FreeBSD Ports: 2.9.9
Ubuntu 16.04 LTS: 2.9.3

Based on this sampling, we can reasonably bump libxml2 min
version to 2.9.1

The 'query_raw' struct field was added in version 2.6.28,
so can be assumed to exist.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 17:21:42 +01:00
Daniel P. Berrangé
b18c273a24 remote: enable connecting to the per-driver daemons
Historically URIs handled by the remote driver will always connect to
the libvirtd UNIX socket. There will now be one daemon per driver, and
each of these has its own UNIX sockets to connect to.

It will still be possible to run the traditional monolithic libvirtd
though, which will have the original UNIX socket path.

In addition there is a virproxyd daemon that doesn't run any drivers,
but provides proxying for clients accessing libvirt over IP sockets, or
tunnelling to the legacy libvirtd UNIX socket path.

Finally when running inside a daemon, the remote driver must not reject
connections unconditionally. For example, the QEMU driver needs to be
able to connect to the network driver. The remote driver must thus be
willing to handle connections even when inside the daemon, provided no
local driver is registered.

This refactoring enables the remote driver to be able to connect to the
per-driver daemons. The URI parameter "mode" accepts the values "auto",
"direct" and "legacy" to control which daemons are connected to.

The client side libvirt.conf config file also supports a "remote_mode"
setting which is used if the URI parameter is not set.

If neither the config file or URI parameter set a mode, then "auto"
is used, whereby the client looks to see which sockets actually exist
right now.

The remote driver will only ever spawn the per-driver daemons, or
the legacy libvirtd. It won't ever try to spawn virtproxyd, as
that is only there for IP based connectivity, or for access from
legacy remote clients.

If connecting to a remote host over any kind of ssh tunnel, for now we
must assume only the legacy socket exists. A future patch will introduce
a netcat replacement that is tailored for libvirt to make remote
tunnelling easier.

The configure arg '--with-remote-default-mode=legacy|direct' allows
packagers to set a default at build time. If not given, it will default
to legacy mode.

Eventually the default will switch to direct mode. Distros can choose
to do the switch earlier if desired. The main blocker is testing and
suitable SELinux/AppArmor policies.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
a067b781e9 build: bump min required gcc to 4.8
The previous bump to 4.4 was done in:

  commit 24241c236e
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Jul 5 10:35:32 2017 +0100

    Require use of GCC 4.4 or CLang compilers

with 4.4 picked due to RHEL-6. Since we dropped RHEL-6, the
next oldest distro is RHEL-7 (4.8.5), and thus we pick 4.8
as the new min.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-07 14:26:12 +01:00
Andrea Bolognani
120465f38a m4: Fix check for yajl.pc
Commit 44b8df4cb4 introduced a check for yajl.pc that is
extremely similar to the one we already had in place for
readline.pc - so similar, in fact, that it's still looking
for readline.pc instead of yajl.pc :)

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-08 12:01:27 +02:00
Daniel P. Berrangé
5a148ce846 remote: delete the avahi mDNS support
Libvirtd has long had integration with avahi for advertising libvirtd
using mDNS when TCP/TLS listening is enabled. For a long time the
virt-manager application had support for auto-detecting libvirtds
on the local network using mDNS, but this was removed last year

  commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
  Author: Cole Robinson <crobinso@redhat.com>
  Date:   Sat Oct 6 20:55:31 2018 -0400

    connect: Drop avahi support

    Libvirtd can advertise itself over avahi. The feature is disabled by
    default though and in practice I hear of no one actually using it
    and frankly I don't think it's all that useful

    The 'Open Connection' wizard has a disproportionate amount of code
    devoted to this feature, but I don't think it's useful or worth
    maintaining, so let's drop it

I've never heard of any other applications having support for using
mDNS to detect libvirtd instances. Though it is theoretically possible
something exists out there, it is clearly going to be a niche use case
in the virt ecosystem as a whole.

By removing avahi integration we can cut down the dependency chain for
the basic libvirtd install and reduce our code maint burden.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-06-21 12:59:42 +01:00
Pavel Hrdina
e0ce339c31 rpc: virnetlibsshsession: update deprecated functions
In libssh 0.9.0 functions ssh_is_server_known and ssh_write_knownhost
are marked as deprecated.

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

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-06-21 09:49:24 +02:00
Michal Privoznik
3c8d5762a9 m4: Drop needless string checks
We provide default values for both MODPROBE and RMMOD and thus
there is no way that their paths can be empty strings.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 15:08:59 +02:00
Michal Privoznik
523b799d3c m4: Provide default value fore UDEVADM
https://bugzilla.redhat.com/show_bug.cgi?id=1710575

It may happen that the system where libvirt is built at doesn't
have udevadm binary but the one where it runs does have it.
If we change how udevadm is run in virWaitForDevices() then we
can safely pass a default value in m4 macro.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 15:08:59 +02:00
Michal Privoznik
2944dcb2de lib: Drop UDEVSETTLE
The udevsettle binary is no longer used anywhere as it was
replaced by 'udevadm settle'. There's no reason for us to even
check for it in configure.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 15:08:59 +02:00
Ján Tomko
02de59ccb6 build: drop check for udev_monitor_set_receive_buffer_size
It has been exported by systemd commit
commit a571c23e954cb88cdd5faa28593b19bd7c340130
    libudev: export udev_monitor_set_receive_buffer_size()
released in v183.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 16:39:46 +02:00
Ján Tomko
385d4b851f build: bump minimum udev version to 219
This is the version of systemd RHEL/CentOS 7 uses:
https://repology.org/project/systemd/versions
Oldest tracked openSUSE distros have 228,
Ubuntu 16.04 has 229 and Gentoo's alternative eudev
has bumped the version to 219 back in 2015.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 16:39:46 +02:00
Pavel Hrdina
91268c715c node_device_udev: remove deprecated logging function
The function was deprecated in udev 219 and all the supported OSes
don't have older version of udev or systemd.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-15 10:42:44 +02:00
Ján Tomko
44b8df4cb4 build: restore support for libyajl 2.0.1
Commit 105756660f was too eager and did
not consider SLES 12 which still has 2.0.1 that does not ship
a pkg-config file.

Similar to how we check for readline, prefer pkg-config if available
and fall back to the old detection code if not found.

NB: this is not a clean revert because we're not reintroducing support
for YAJL 1.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reported-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-05-10 13:10:57 +02:00
Andrea Bolognani
9d7b9cf166 Fix spelling for macOS
Though it used to be called "Mac OS X" and "OS X" in the past,
it was never "MacOS X" nor "OS-X", and it's just "macOS" now.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2019-04-15 11:09:10 +02:00
Andrea Bolognani
dfe06e6202 m4: readline: Add gross kludge for include path
Unfortunately the data reported by pkg-config is not completely
accurate, so until the issue has been fixed in readline we need
to work around it in libvirt.

The good news is that we only need the fix to land in FreeBSD
ports and macOS homebrew before we can drop the kludge, so
we're talking months rather than years.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:32 +02:00
Andrea Bolognani
c98de2173e m4: readline: Use pkg-config where possible
With the 7.0 release, readline has finally started shipping
pkg-config support in the form of a readline.pc file.

Unfortunately, most downstreams have yet to catch up with this
change: among Linux distributions in particular, Fedora Rawhide
seems to be the only one installing it at the moment.

Non-Linux operating systems have been faring much better in
this regard: both FreeBSD (through ports) and macOS (through
homebrew) include pkg-config support in their readline package.

This is great news for us, since those are the platforms where
pkg-config is more useful on account of them installing headers
and libraries outside of the respective default search paths.

Our implementation checks whether readline is registered as a
pkg-config package, and if so obtains CFLAGS and LIBS using the
tool; if not, we just keep using the existing logic.

This commit is best viewed with 'git show -w'.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:29 +02:00
Andrea Bolognani
c6921fd0be m4: readline: Drop extra_LIBS machinery
The first implementation of this logic was introduced with
commit 2ec759fc58 all the way back in 2007; looking at the
build logs from our CI environment, however, it's apparent
that none of the platforms we currently target are actually
using it, so we can assume whatever issue it was working
around has been fixed at some point in the last 12 years.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:26 +02:00
Andrea Bolognani
9a063767f4 m4: readline: Extract code setting -D_FUNCTION_DEF
The current code is a bit awkward, and we're going to need
to share it later anyway. We can drop the call to AC_SUBST()
while we're at it, since LIBVIRT_CHECK_LIB() already marks
READLINE_CFLAGS for substitution.

The new code goes to some extra length to avoid setting
-D_FUNCTION_DEF twice: this is mostly for cosmetic reasons,
and it's necessary because LIBVIRT_CHECK_READLINE() is called
twice: once on its own, and then once more as part of
LIBVIRT_CHECK_BASH_COMPLETION().

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:23 +02:00
Andrea Bolognani
a9443bc9a9 m4: readline: Comment rl_completion_quote_character() check
The check was added in 74416b1d48 without offering any
explanation outside of the commit message. Introduce a comment
to make digging through the git history unnecessary.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:20 +02:00
Andrea Bolognani
765acbe398 m4: readline: Fix indentation
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:22:18 +02:00
Andrea Bolognani
ab6f29c6da m4: sasl: Use pkg-config
Since commit 4e75b0a00f we support SASL 2.1.26 and newer
releases only, all of which ship a .pc file. Using pkg-config
allows FreeBSD builds to pick up the dependency automatically.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 09:16:08 +02:00
Ján Tomko
f13bf4518b build: remove WITH_YAJL2
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-03 13:30:47 +02:00
Ján Tomko
105756660f build: require yajl >= 2.0.3
The pkg-config file was introduced by commit b729ded which was released
in yajl 2.0.3.

Since all our supported platforms include at least yajl 2.0.4,
use pkg-config to detect the library and set the minimum to 2.0.3.

https://repology.org/project/yajl/versions

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-03 13:30:47 +02:00
Ján Tomko
4e75b0a00f build: drop check for SASL1
Even Debian 8 which we no longer support has 2.1.26.

https://repology.org/project/cyrus-sasl/versions

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-03 13:30:46 +02:00
Andrea Bolognani
e5e23e3fb9 m4: Add warning when running QEMU as root
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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-26 18:30:26 +01:00
Andrea Bolognani
29cd1877ac m4: Run QEMU under a distro-specific user when possible
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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-26 18:30:24 +01:00
Daniel P. Berrangé
3aa190f2a4 storage: add support for new rbd_list2 method
The rbd_list method has been deprecated in Ceph >= 14.0.0
in favour of the new rbd_list2 method which populates an
array of structs.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-18 15:21:10 +00:00
Andrea Bolognani
cf6b65a19e m4: Simplify LIBVIRT_CHECK_INIT_SCRIPT
Now that we no longer support the weird "redhat+systemd"
configuration, we can make our code slightly simpler.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-15 18:36:19 +01:00
Andrea Bolognani
912fe2df9d Drop support for "Red Hat" init scripts
Despite the misleading name, these were supposed to be used
with a System V style init; however, none of the platforms we
target is using that kind of init anymore: almost all Linux
distributions have switched to systemd, those that haven't
(such as Gentoo and Alpine) are mostly using OpenRC with
custom init scripts, and the BSDs have been doing their own
thing all along.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-15 18:36:19 +01:00
Andrea Bolognani
b8cfdee42b Drop support for Upstart init scripts
Not a single one of the platforms we target still uses Upstart, and
the Upstart project itself has been abandoned for several years now.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-15 18:36:19 +01:00
Michal Privoznik
2a00ef6e71 virt-driver-qemu.m4: Require YAJL
There is no way that qemu driver can work without being able to
format/parse JSON.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-03-14 17:27:56 +01:00
Michal Privoznik
5f2adfab59 virt-driver-qemu.m4: Make qemu driver optional
The basic idea of our configure script is to probe for things
rather than have them enabled by default. This is even more
visible in the next commit where configure fails if qemu driver
is enabled but no yajl is found.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-03-14 17:27:49 +01:00
Michal Privoznik
0b3f7ec884 virt-yajl.m4: Drop useless check for qemu
The code tries to detect installed version of qemu to learn if it
uses HMP or QMP and enable YAJL based on that. Well, we support
only QMP and also minimal required version of qemu is 1.5.0 so
the check would have enabled yajl anyway.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-03-14 14:29:48 +01:00
Michal Privoznik
1620bb0a30 tools: Drop support for pre-2.4.0 wireshark
The wireshark-2.4.0 is almost 2 years old now. Assuming anybody
interested in running latest libvirt doesn't run old wireshark,
it is safe to do this. It also simplifies the code.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 09:22:59 +01:00
Michal Privoznik
dc93997a83 m4: Put wireshark plugin into epan/ directory
Since wirshark-2.5.0 toplevel plugins are no longer loaded. Only
plugins from epan/, wiretap/ or codecs/ subdirs are. Update the
plugin dir we generate. This is safe to do even for older
wiresharks, since they load plugins from there too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 09:22:59 +01:00
Laine Stump
3b71f2e42d configure: selectively install a firewalld 'libvirt' zone
In the past (when both libvirt and firewalld used iptables), if either
libvirt's rules *OR* firewalld's rules accepted a packet, it would
be accepted. This was because libvirt and firewalld rules were
processed during the same kernel hook, and a single ACCEPT result
would terminate the rule traversal and cause the packet to be
accepted.

But now firewalld can use nftables for its backend, while libvirt's
firewall rules are still using iptables; iptables rules are still
processed, but at a different time during packet processing
(i.e. during a different hook) than the firewalld nftables rules. The
result is that a packet must be accepted by *BOTH* the libvirt
iptables rules *AND* the firewalld nftable rules in order to be
accepted.

This causes pain because

1) libvirt always adds rules to permit DNS and DHCP (and sometimes
TFTP) from guests to the host network's bridge interface. But
libvirt's bridges are in firewalld's "default" zone (which is usually
the zone called "public"). The public zone allows ssh, but doesn't
allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the
DHCP and DNS traffic, the firewalld rules (now processed during a
different hook) dont, thus guests connected to libvirt's bridges can't
acquire an IP address from DHCP, nor can they make DNS queries to the
DNS server libvirt has setup on the host. (This could be solved by
modifying the default firewalld zone to allow DNS and DHCP, but that
would open *all* interfaces in the default zone to those services,
which is most likely not what the host's admin wants.)

2) Even though libvirt adds iptables rules to allow forwarded traffic
to pass the iptables hook, firewalld's higher level "rich rules" don't
yet have the ability to configure the acceptance of forwarded traffic
(traffic that is going somewhere beyond the host), so any traffic that
needs to be forwarded from guests to the network beyond the host is
rejected during the nftables hook by the default zone's "default
reject" policy (which rejects all traffic in the zone not specifically
allowed by the rules in the zone, whether that traffic is destined to
be forwarded or locally received by the host).

libvirt can't send "direct" nftables rules (firewalld only supports
direct/passthrough rules for iptables), so we can't solve this problem
by just sending explicit nftables rules instead of explicit iptables
rules (which, if it could be done, would place libvirt's rules in the
same hook as firewalld's native rules, and thus eliminate the need for
packets to be accepted by both libvirt's and firewalld's own rules).

However, we can take advantage of a quirk in firewalld zones that have
a default policy of "accept" (meaning any packet that doesn't match a
specific rule in the zone will be *accepted*) - this default accept will
also accept forwarded traffic (not just traffic destined for the host).

Of course we don't want to modify firewalld's default zone in that
way, because that would affect the filtering of traffic coming into
the host from other interfaces using that zone. Instead, we will
create a new zone called "libvirt". The libvirt zone will have a
default policy of accept so that forwarded traffic can pass and list
specific services that will be allowed into the host from guests (DNS,
DHCP, SSH, and TFTP).

But the same default accept policy that fixes forwarded traffic also
causes *all* traffic from guest to host to be accepted. To close this
new hole, the libvirt zone can take advantage of a new feature in
firewalld (currently slated for firewalld-0.7.0) - priorities for rich
rules - to add a low priority rule that rejects all local traffic (but
leaves alone all forwarded traffic).

So, our new zone will start with a list of services that are allowed
(dhcp, dns, tftp, and ssh to start, but configurable via any firewalld
management application, or direct editing of the zone file in
/etc/firewalld/zones/libvirt.xml), followed by a low priority
<reject/> rule (to reject all other traffic from guest to host), and
finally with a default policy of accept (to allow forwarded traffic).

This patch only creates the zonefile for the new zone, and implements
a configure.ac option to selectively enable/disable installation of
the new zone. A separate patch contains the necessary code to actually
place bridge interfaces in the libvirt zone.

Why do we need a configure option to disable installation of the new
libvirt zone? It uses a new firewalld attribute that sets the priority
of a rich rule; this feature first appears in firewalld-0.7.0 (unless
it has been backported to am earlier firewalld by a downstream
maintainer). If the file were installed on a system with firewalld
that didn't support rule priorities, firewalld would log an error
every time it restarted, causing confusion and lots of extra bug
reports.

So we add two new configure.ac switches to avoid polluting the system
logs with this error on systems that don't support rule priorities -
"--with-firewalld-zone" and "--without-firewalld-zone". A package
builder can use these to include/exclude the libvirt zone file in the
installation. If firewalld is enabled (--with-firewalld), the default
is --with-firewalld-zone, but it can be disabled during configure
(using --without-firewalld-zone). Targets that are using a firewalld
version too old to support the rule priority setting in the libvirt
zone file can simply add --without-firewalld-zone to their configure
commandline.

These switches only affect whether or not the libvirt zone file is
*installed* in /usr/lib/firewalld/zones, but have no effect on whether
or not libvirt looks for a zone called libvirt and tries to use it.

NB: firewalld zones can only be added to the permanent config of
firewalld, and won't be loaded/enabled until firewalld is restarted,
so at package install/upgrade time we have to restart firewalld. For
rpm-based distros, this is done in the libvirt.spec file by calling
the %firewalld_restart rpm macro, which is a part of the
firewalld-filesystem package. (For distros that don't use rpm
packages, the command "firewalld-cmd --reload" will have the same
effect).

Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-01 12:08:37 -05:00
Laine Stump
4bf0f390ed configure: change HAVE_FIREWALLD to WITH_FIREWALLD
Support for firewalld is a feature that can be selectively enabled or
disabled (using --with-firewalld/--without-firewalld), not merely
something that must be accounted for in the code if it is present with
no exceptions. It is more consistent with other usage in libvirt to
use WITH_FIREWALLD rather than HAVE_FIREWALLD.

Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-01 12:08:37 -05:00
Michal Privoznik
29682196d8 Drop UML driver
The driver is unmaintained, untested and severely broken for
quite some time now. Since nobody even reported any issue with it
let us drop it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-17 17:52:46 +01:00
Marek Marczykowski-Górecki
aca7ff5f70 libxl: add support for PVH
Since this is something between PV and HVM, it makes sense to put the
setting in place where domain type is specified.
To enable it, use <os><type machine="xenpvh">xenpvh</type></os>. It is
also included in capabilities.xml, for every supported HVM guest type - it
doesn't seems to be any other requirement (besides new enough Xen).

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-11-26 16:31:21 -07:00
Jim Fehlig
dc3d2c9f8c libxl: fallback to lib probe if pkgconfig file not found
With the assumption that all Xen >= 4.6 contains a pkgconfig file for
libxenlight, commit 5bdcef13 dropped the fallback check to probe
libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
the various Xen pkgconfig files are in the -runtime package in Fedora,
instead of the traditional -devel package. This bug [1] was fixed in
Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
the fallback check.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2018-09-20 07:59:26 -06:00
Jim Fehlig
e44840c441 build: remove unused variables from virt-driver-libxl.m4
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2018-09-20 07:59:26 -06:00