Commit Graph

761 Commits

Author SHA1 Message Date
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é
60ee70e93e vbox: introduce virtvboxd daemon
The virtvboxd daemon will be responsible for providing the vbox API
driver functionality. The vbox driver is still loaded by the main
libvirtd daemon at this stage, so virtvboxd must not be running at
the same time.

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é
23ab0f0bef lxc: introduce virtlxcd daemon
The virtlxcd daemon will be responsible for providing the lxc API
driver functionality. The lxc driver is still loaded by the main
libvirtd daemon at this stage, so virtlxcd must not be running at
the same time.

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é
bb1021e369 qemu: introduce virtqemud daemon
The virtqemud daemon will be responsible for providing the qemu API
driver functionality. The qemu driver is still loaded by the main
libvirtd daemon at this stage, so virtqemud must not be running at
the same time.

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é
12e30d1e54 libxl: introduce virtxend daemon
The virtxend daemon will be responsible for providing the libxl API
driver functionality. The libxl driver is still loaded by the main
libvirtd daemon at this stage, so virtxend must not be running at
the same time.

This naming is slightly different than other drivers. With the libxl
driver, the user still has a 'xen:///system' URI, and we provide it
in a libvirt-daemon-xen RPM, which pulls in a
libvirt-daemon-driver-libxl RPM.

Arguably we could rename the libxl driver to "xen" since it is the
only xen driver we have these days, and that matches how we expose it
to users in the URI naming.

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é
653ddc2e64 nwfilter: introduce virtnwfilterd daemon
The virtnwfilterd daemon will be responsible for providing the nwfilter API
driver functionality. The nwfilter driver is still loaded by the main
libvirtd daemon at this stage, so virtnwfilterd must not be running at
the same time.

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é
e4de8857ad nodedev: introduce virtnodedevd daemon
The virtnodedevd daemon will be responsible for providing the nodedev API
driver functionality. The nodedev driver is still loaded by the main
libvirtd daemon at this stage, so virtnodedevd must not be running at
the same time.

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é
e23d5b0435 storage: introduce virtstoraged daemon
The virtstoraged daemon will be responsible for providing the storage API
driver functionality. The storage driver is still loaded by the main
libvirtd daemon at this stage, so virtstoraged must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
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é
62d817a328 interface: introduce virtinterfaced daemon
The virtinterfaced daemon will be responsible for providing the interface API
driver functionality. The interface driver is still loaded by the main
libvirtd daemon at this stage, so virtinterfaced must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
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é
1c27cef1e3 network: introduce virtnetworkd daemon
The virtnetworkd daemon will be responsible for providing the network API
driver functionality. The network driver is still loaded by the main
libvirtd daemon at this stage, so virtnetworkd must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
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é
d353d57fcd secret: introduce virtsecretd daemon
The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.

Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
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é
b7ed8ce981 remote: introduce virtproxyd daemon to handle IP connectivity
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.

In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.

We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.

In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.

It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.

Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.

Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).

We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages

 - We can make virtproxyd and the virtXXXd per-driver daemons all
   have "Conflicts: libvirtd.service" in their systemd unit files.
   This will guarantee that libvirtd is never started at the same
   time, as this would result in two daemons running the same driver.
   Fortunately drivers use locking to protect themselves, but it is
   better to avoid starting a daemon we know will conflict.

 - It allows us to break CLI compat to remove the --listen parameter.
   Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
   will default to zero. Either TLS or TCP can be enabled exclusively
   though virtd.conf without requiring the extra step of adding --listen.

 - It allows us to set a strict SELinux policy over virtproxyd. For
   back compat the libvirtd policy must continue to allow all drivers
   to run. We can't easily give a second policy to libvirtd which
   locks it down. By introducing a new virtproxyd we can set a strict
   policy for that daemon only.

 - It gets rid of the weird naming of having a daemon with "lib" in
   its name. Now all normal daemons libvirt ships will have "virt"
   as their prefix not "libvirt".

 - Distros can more easily choose their upgrade path. They can
   ship both sets of daemons in their packages, and choose to
   either enable libvirtd, or enable the per-driver daemons and
   virtproxyd out of the box. Users can easily override this if
   desired by just tweaking which systemd units are active.

After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.

The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.

The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.

The aggressive option is to disable libvirtd if already running
and activate all the new daemons.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-09 14:06:31 +01:00
Daniel P. Berrangé
4feeb2d986 tools: split virt-login-shell into two binaries
The virt-login-shell binary is a setuid program that takes
no arguments. When invoked it looks at the invoking uid,
resolves it to a username, and finds an LXC guest with the
same name. It then starts the guest and runs the shell in
side the namespaces of the container.

Given this set of tasks the virt-login-shell binary needs
to connect to libvirtd, make various other libvirt API calls.
This is a problem for setuid binaries as various libraries
that libvirt.so links to are not safe. For example, they have
constructor functions which execute an unknown amount of code
that can be influenced by env variables.

For this reason virt-login-shell doesn't use libvirt.so,
but instead links to a custom, cut down, set of source files
sufficient to be a local client only.

This introduces a problem for integrating glib2 into libvirt
though, as once integrated, there would be no way to build
virt-login-shell without an external dependancy on glib2 and
this is definitely not setuid safe.

To resolve this problem, we split the virt-login-shell binary
into two parts. The first part is setuid and does almost
nothing. It simply records the original uid+gid, and then
invokes the virt-login-shell-helper binary. Crucially when
it does this it completes scrubs all environment variables.
It is thus safe for virt-login-shell-helper to link to the
normal libvirt.so. Any things that constructor functions
do cannot be influenced by user control env vars or cli
args.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-07 16:54:01 +01:00
Eric Blake
0d44788fc3 backup: Introduce virDomainCheckpoint APIs
Introduce a bunch of new public APIs related to backup checkpoints.
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.  We may have a future hypervisor that can completely manage
checkpoints without libvirt metadata, but the first two planned
hypervisors (qemu and test) both always use libvirt for tracking
metadata relations between checkpoints, so for now, I've deferred
the counterpart of virDomainSnapshotHasMetadata for a separate
API addition at a later date if there is ever a need for it.

Note that until we allow snapshots and checkpoints to exist
simultaneously on the same domain (although the actual prevention of
this will be in a separate patch for the sake of an easier revert down
the road), that it is not possible to branch out to create more than
one checkpoint child to a given parent, although it may become
possible later when we revert to a snapshot that coincides with a
checkpoint.  This also means that for now, the decision of which
checkpoint becomes the parent of a newly created one is the only
checkpoint with no child (so while there are APIs for dealing with a
current snapshot, we do not need those for checkpoints).  We may end
up exposing a notion of a current checkpoint later, but it's easier to
add stuff when proven needed than to blindly support it now and wish
we hadn't exposed it.

The following map shows the API relations to snapshots, with new APIs
on the right:

Operate on a domain object to create/redefine a child:
virDomainSnapshotCreateXML          virDomainCheckpointCreateXML

Operate on a child object for lifetime management:
virDomainSnapshotDelete             virDomainCheckpointDelete
virDomainSnapshotFree               virDomainCheckpointFree
virDomainSnapshotRef                virDomainCheckpointRef

Operate on a child object to learn more about it:
virDomainSnapshotGetXMLDesc         virDomainCheckpointGetXMLDesc
virDomainSnapshotGetConnect         virDomainCheckpointGetConnect
virDomainSnapshotGetDomain          virDomainCheckpointGetDomain
virDomainSnapshotGetName            virDomainCheckpiontGetName
virDomainSnapshotGetParent          virDomainCheckpiontGetParent
virDomainSnapshotHasMetadata        (deferred for later)
virDomainSnapshotIsCurrent          (no counterpart, see note above)

Operate on a domain object to list all children:
virDomainSnapshotNum                (no counterparts, these are the old
virDomainSnapshotListNames           racy interfaces)
virDomainSnapshotListAllSnapshots   virDomainListAllCheckpoints

Operate on a child object to list descendents:
virDomainSnapshotNumChildren        (no counterparts, these are the old
virDomainSnapshotListChildrenNames   racy interfaces)
virDomainSnapshotListAllChildren    virDomainCheckpointListAllChildren

Operate on a domain to locate a particular child:
virDomainSnapshotLookupByName       virDomainCheckpointLookupByName
virDomainSnapshotCurrent            (no counterpart, see note above)
virDomainHasCurrentSnapshot         (no counterpart, old racy interface)

Operate on a snapshot to roll back to earlier state:
virDomainSnapshotRevert             (no counterpart, instead checkpoints
                                     are used in incremental backups via
				     XML to virDomainBackupBegin)

Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-26 16:48:58 -05:00
Eric Blake
d85842cfd7 backup: Document new XML for checkpoints
Prepare for new checkpoint APIs by describing the XML that will
represent a checkpoint.  The checkpoint XML is modeled heavily after
virDomainSnapshotPtr. See the docs for more details.

Add testsuite coverage for some minimal uses of the XML (bare minimum,
the sample from html, and a full dumpxml, and some counter-examples
that should fail schema validation). Although use of the REDEFINE flag
will require the <domain> subelement to be present, it is easier for
most of the tests to provide counterpart output produced with the
NO_DOMAIN flag (particularly since synthesizing a valid <domain>
during testing is not trivial).

Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-26 16:48:58 -05:00
Daniel P. Berrangé
2c3e08b0e3 remote: add systemd socket units for UNIX/TCP sockets
We don't do socket activation of libvirtd, since we need to
unconditionally start libvirtd in order to perform autostart. This
doesn't mean we can't have systemd socket units. Some use cases will
not need libvirt's autostart & are thus free to use activation.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-12 16:55:40 +01: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
Daniel P. Berrangé
4b4a981d60 conf: introduce virNetworkPortDefPtr struct and XML support
Introduce a virNetworkPortDefPtr struct to represent the data associated
with a virtual network port. Add APIs for parsing/formatting XML docs
with the data.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-06-17 15:19:54 +01:00
Andrea Bolognani
925bfbd809 examples: Install Polkit examples
Right now we install the files in RPMs only, and we include
them in the -daemon package which is probably not the best
option either. Start installing them via autotools; the RPMs
will get them automatically in the -docs package.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-03 17:27:28 +02:00
Andrea Bolognani
4f274bd7e3 spec: Don't install libvirt-api.xml as documentation
We already install the file, along with its driver-specific
counterparts, into ${datadir}/libvirt/api/ where language
bindings will actually look for them.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-03 17:27:03 +02:00
Andrea Bolognani
f8c734572c spec: Improve handling for default network
This is exactly how we already treat nwfilters, which require
the same kind of care (aka nasty hacks) as the default network,
because in both cases the UUID is generated and written to
disk the first time libvirtd is started after installing the
corresponding subpackage.

After this patch, RPM will be aware of the fact that the
libvirt-daemon-config-network subpackage owns the default
network.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-05-27 15:24:05 +02:00
Jiri Denemark
7cf7eab52d spec: Fix permissions of /var/run/libvirt/qemu
While libvirtd creates this directory with the default 0755 mode, the
spec file stores 0700 in the RPM database. Thus RPM verification always
complains about this directory. Let's fix the spec file to match
reality.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2019-05-27 15:00:11 +02:00
Jiri Denemark
f87d5a964f spec: Fix permissions of nwfilter XMLs
The nwfilter XML files stored in /etc/libvirt/nwfilter are copied in a
%post scriptlet from /usr/share/libvirt/nwfilter/*.xml. While the files
in /usr/share are created with mode 0644, libvirt creates the files in
/etc/libvirt/nwfilter with mode 0600. Since 0600 is also stored in the
RPM database, we need to chmod the files copied from /usr/share to make
sure RPM verification does not complain about changed permissions.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-05-27 15:00:11 +02:00
Jiri Denemark
e67b0a4576 spec: Unconditionally set ownership of /var/lib/libvirt/sanlock
The libvirt-lock-sanlock subpackage requires sanlock to be installed
first and the sanlock package creates the sanlock group on all distros
we care about in the spec file (Fedora and RHEL >= 7). Thus instead of
setting the ownership and permissions in a post scriptlet only when the
sanlock group exists we can just install the directory with the
appropriate metadata.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-05-27 15:00:11 +02:00
Daniel P. Berrangé
06a61a202c rpm: remove dependancy from qemu to network/storage drivers
The libvirt-daemon-driver-qemu RPM has historically had a hard
dependency on the libvirt-daemon-driver-network and
libvirt-daemon-driver-storage-core packages. This was because the QEMU
driver would directly call into APIs that were part of these drivers.

The dependency to the storage driver was eliminated in

  commit 064fec69be
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Jan 25 09:35:46 2018 +0000

    storage: move storage file backend framework into util directory

The dependency to the network driver was eliminated in

  commit 5b13570ab8
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Jan 25 09:35:47 2018 +0000

    conf: introduce callback registration for domain net device allocation

  commit 1438aea4ee
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Jan 25 09:35:48 2018 +0000

    conf: expand network device callbacks to cover bandwidth updates

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-05-20 12:27:37 +01:00
Andrea Bolognani
4faaaa8b27 examples: Install under $(docdir)
Our build system doesn't currently install the various
example programs provided along libvirt; however, both the
upstream .spec file and the Debian packaging go out of
their way to make sure these useful demos are included in
the respective documentation packages.

Moreover, doing so without help from the upstream build
system is easy to get wrong: the libvirt-docs RPM package,
for example, ends up missing one of the examples and
including a bunch of empty .deps/ directories.

Install the examples in $(docdir) as part of our regular
procedure, so that users and downstreams don't have to do
anything special about them.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-05-13 12:02:17 +02:00
Andrea Bolognani
6716c997f6 docs: Install documentation under $(docdir)
At the moment we allow the user to specify exactly where
they want the HTML documentation to be installed with an
extreme level of precision through the --with-html-dir and
--with-html-subdir configure options.

Most of the time, of course, the user will stick with the
default, that is $(datadir)/doc/$(PACKAGE)-$(VERSION)/html.

So close to $(docdir)! Including the version number in
the path, specifically, seems entirely unnecessary since
different releases of libvirt are not going to be able to
coexist on the same system anyway.

Drop all these custom flexibilty for flexibilty's sake
shenaningans in favor of the standard, well understood
$(docdir).

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
2019-05-13 12:02:13 +02:00
Andrea Bolognani
8a1179831b spec: Bump minimum supported Fedora version to 29
Fedora 30 is out, which means that Fedora 28 is going to be
EOL very soon. Let's get ahead of the game and drop support
for it right now.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-05-09 15:08:03 +02:00
Cole Robinson
25c4b01662 spec: fix f28 rpm without firewalld zone
Commit 3b71f2e42d added spec handling for with_firewalld_zone. We
now call %firewalld_reload if with_firewalld is set. But the matching
'BuildRequires: firewalld-filesystem' is only applied if
with_firewalld_zone is set.

Fix the former bit to use with_firewalld_zone

Reviewed-by: Laine Stump <laine@laine.org>
Reported-by: Yuval Turgeman <yturgema@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-04-30 14:08:08 -04:00
Laine Stump
65b08aff08 build: set --without-firewalld-zone in configure commandline for Fedora 30
The firewalld package in Fedora 30 didn't get support for rich rule
priorities, which is required by the libvirt zonefile that's installed
when the build is configured with --with-firewalld-zone, so we need to
set --without-firewalld-zone for that version of Fedora. The needed
feature is already upstream in firewalld, so it just needs another
upstream release to be there. Let's be optimistic and assume that will
happen prior to F31.

Resolves: https://bugzilla.redhat.com/1699051
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Eric Garver <eric@garver.life>
2019-04-11 14:29:31 -04:00
Andrea Bolognani
d2d875fd2f spec: Move ldconfig calls from -client to -libs
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 70b4f0e719, 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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-03-27 10:59:54 +01:00
Cole Robinson
8d09acf66d spec: Remove libvirt < 0.9.4 upgrade compat
These blocks are only triggered when updating from a libvirt version
less than 0.9.4, which was released in August 2011. I think it's been
long enough that we can say this upgrade path is unsupported without
an intermediate step.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-22 11:32:46 -04:00
Cole Robinson
769eab7d78 spec: Only call ldconfig on RHEL7
Since Fedora 28 (our minimum supported build), ldconfig is called
automatically for us:

https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets

These changes appear to be implemented for RHEL > 7 as well, so only
run ldconfig on RHEL7

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-22 11:32:45 -04:00
Daniel P. Berrangé
fc65c22b73 rpm: fix upgrades when RBD is disabled in a new version
We previously had to disable RBD on 32-bit platforms since Ceph has
dropped all support for 32-bit. Unfortunately anyone with the RPM
libvirt-daemon-driver-storage-rbd installed on 32-bit now has a
broken upgrade path.

To fix this we must make libvirt-daemon-driver-storage-core
have an Obsoletes: libvirt-daemon-driver-storage-rbd < $VER-$REL

Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-20 17:05:23 +00:00
Daniel P. Berrangé
81c5e75e57 rpm: add dep on xfsprogs-devel for reflink support
Support for XFS reflink clone was added in:

  commit 8ed874b39b
  Author: Julio Faracco <jcfaracco@gmail.com>
  Date:   Fri Jul 6 10:43:01 2018 -0300

    storage: Rename btrfsCloneFile to support other filesystems.

  commit 2e11298f93
  Author: Julio Faracco <jcfaracco@gmail.com>
  Date:   Fri Jul 6 10:43:00 2018 -0300

    configure: Adding XFS library/headers check.

But these patches missed that the xfs/xfs.h header is not installed
unless you have xfsprogs-devel present.

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-07 11:46:16 +00:00
John Ferlan
5dded8c806 docs: Add schema for storage pool capabilities
Define a schema for the storage pool capabilities along with
a test to show the general format.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2019-03-06 11:12:48 -05: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
Daniel P. Berrangé
388998ac76 rpm spec: remove %{extra_release} from spec
The %{extra_release} field was previously populated by data from the old
autobuild.sh file but is no longer used.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-22 11:16:08 +00:00
Daniel P. Berrangé
635c45a925 rpm spec: don't assume %{fedora} exists as a macro
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-21 14:05:35 +00:00
Daniel P. Berrangé
6c6001bddb rpm spec: disable ceph on 32-bit architectures
Ceph in upstream and Fedora has dropped support for building on host
architectures which are 32-bit.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-21 12:20:14 +00: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
Andrea Bolognani
2569ba1338 spec: Drop support for Fedora 27
In accordance with our platform support policy, now that
Fedora 29 is out we no longer support building on Fedora 27.

This allows us to remove a few version checks.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-11-08 14:01:07 +01:00
Daniel P. Berrangé
87f71398fe rpm: disable some features on riscv64
numctl, numad and zfs-fuse are not available on riscv64 targets

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-10-05 13:59:31 +01:00
Jiri Denemark
b1a0f691ce spec: Build ceph and gluster support everywhere
Both ceph and gluster have been built on RHEL on all architectures for
some time, there's no need to limit them to x86_64.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-09-27 17:32:40 +02:00
Jiri Denemark
8004767030 spec: Set correct TLS priority
RHEL-7 is the only system where gnutls is too old to support @LIBVIRT
specifier.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-09-27 17:32:40 +02:00
Fabiano Fidêncio
b3b7b38092 rpm: increase min required Fedora to 27
Fedora 26 has reached its EOL on May 29th 2018.

https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/message/XGG7GYUJN3VDA6HX4KJNFSKSQCGF2FMW/

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-09-11 08:52:27 +02:00
Daniel P. Berrangé
3ecbac95cd cpu: move the CPU map data files into a src/cpu_map directory
In preparation for splitting up the CPU map data file, move it into a
dedicated directory of its own.

Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-28 12:08:21 +01:00
Cole Robinson
a408a6dae8 spec: Add firmware/nvram paths for edk2 arm and ia32
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2018-08-16 09:16:45 -04:00