As of fedora polkit-0.113-2, polkit-devel only pulls in polkit-libs, not
full polkit, but we need the latter for pkcheck otherwise our configure
test fails.
Don't listen on the admin socket in the daemon and comment out the
admin devel files out of specfile.
Library is still being compiled and installed in order to link easily
without any disturbing modifications to the daemon code.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Its only file must be included in the daemon package anyway, since the
daemon is linked with the admin library and so then it's just an empty
package until we have virt-admin binary which we can decide later on
whether to just move it to clients or create a new package for it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
While Martin introduced the binary (and its manpage) in commit
4e7ccf8713 it was pushed by mistake. Therefore it was reverted in
220393bfb0. The problem is, the original commit was not quite right
as the binary was added into the spec file in a different commit:
55e0c840af. So as long as the binary does not exist, we must remove it
from the spec file too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
No online docs are build from it since it doesn't really fit into our
document structure and new page will need to be created for it, but this
is at least a heads-up commit for easier parsing in order to build some
documentation (or python bindings) later on.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Initial scratch of the admin library. It has its own virAdmConnectPtr
that inherits from virAbstractConnectPtr and thus trivially supports
error reporting.
There's pkg-config file added and spec-file adjusted as well.
Since the library should be "minimalistic" and not depend on any other
library, the list of files is especially crafted for it. Most of them
could've been put to it's own sub-libraries that would be LIBADD'd to
libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize
the number of object files being built, but that's a refactoring that
isn't the orginal aim of this commit.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Commit 198cc1d3 introduced libxl-lockd and libxl-sanlock config
files but forgot to add them to the spec file. Follow-up commit
62b18d98 added the files to daemon-driver-libxl, but missed adding
them to the daemon package when configuring libvirt
--without-driver-modules. In addition, commit 62b18d98 added
libxl-sanlock to daemon-driver-libxl, but it should be included
in lock-sanlock when libvirt is configured --with-sanlock.
Many users, who admin their own machines, want to be able to access
system libvirtd via tools like virt-manager without having to enter
a root password. Just google 'virt-manager without password' and
you'll find many hits. I've read at least 5 blog posts over the years
describing slightly different ways of achieving this goal.
Let's finally add official support for this.
Install a polkit-1 rules file granting password-less auth for any user
in the new 'libvirt' group. Create the group on RPM install
https://bugzilla.redhat.com/show_bug.cgi?id=957300
Recent commit 198cc1d3 introduced integration of lockd and sanlock into
libxl, but forget to update libvirt.spec.in to also list new files
distributed via package.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Fedora doesn't ship OVMF/AAVMF builds in its repos due to licensing
issues, so the recommended way to consume these bits is via Gerd's
nightly repo: https://www.kraxel.org/repos
Let's teach fedora builds about the loader/nvram pairs these packages
installed, so users don't need to edit qemu.conf to get virt-manager
UEFI support.
Introduce libxl.conf configuration file, adding the 'autoballoon'
setting as the first knob for controlling the libxl driver.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Apparently, files in /usr/lib/sysctl.d are usually prefixed with numbers
for easier ordering. Let's be consistent with this. I chose 60 for
libvirtd so that it goes after 50-default.conf.
https://bugzilla.redhat.com/show_bug.cgi?id=1084876
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit 55ea7be7 removed separated modules for vbox_network and
vbox_storage drivers but forget to update libvirt.spec.in file. This
patch will fix rpm build.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Since we switched to using GIT to apply patches in the RPM spec,
we automagically also turned on -Werror, since the .git directory
now exists. We don't want this on in Fedora, since changing
header files often lead to new warnings being issued. Explicitly
turn off -Werror for non-RHEL platforms, instead of relying on
the defaults
The module XML::XPath is needed when building from git only (no need to
have it when building from tarball), so this patch moves the check from
specfile into bootstrap.conf.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Partially reverts commit 5754dbd.
The code in the specfile adds a MAC address to every <bridge>,
even for <forward mode='bridge'> for which we don't support
changing MAC addresses.
Remove it completely. For new networks, we have been adding
MAC addresses on definition/creation since the commit mentioned above.
For existing networks (pre-0.9.0), the MAC is added by this commit.
https://bugzilla.redhat.com/show_bug.cgi?id=1156367
Since libvirt.h was split into multiple files and similarly
docs/libvirt-libvirt.html, docs/hvsupport.html have bad hyperlinks. The
same happens for all the html.in files that used <code class='docref'>
tag, because page.xsl has no idea where to point the link that's found.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
With this change, any patch declared in libvirt.spec with Patch[0-9]* is
automatically applied in %prep. Unlike with the standard %patch[0-9]*,
patches are applied with "git am" to avoid some unexpected results.
However, as a result of this, all patches must be in the right format
for "git am" to be able to apply them; they should ideally be generated
from git using "git format-patch".
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Create a new libvirt-host.h file to hold the public
API definitions for the virConnect type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-domain.h file to hold the public
API definitions for the virDomain type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-event.h file to hold the public
API definitions for the virEvent type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-storage.h file to hold the public
API definitions for the virStorage/Vol type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-stream.h file to hold the public
API definitions for the virStream type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Note the definition of virStreamPtr is not moved, since that
must be declared early for all other libvirt APIs to be able
to reference it.
Create a new libvirt-secret.h file to hold the public
API definitions for the virSecret type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-nodedev.h file to hold the public
API definitions for the virNodeDevice type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-nwfilter.h file to hold the public
API definitions for the virNWFilter type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-interface.h file to hold the public
API definitions for the virInterface type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-network.h file to hold the public
API definitions for the virNetwork type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-domain-snapshot.h file to hold the public
API definitions for the virDomainSnapshot type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
This is a folloup to commit 5f719596, which checks for a route
conflicting with the standard libvirt default network subnet
(192.168.122.0/24). It turns out that $() strips the trailing newline
from the output of "ip route show", so there would be no match if the
route we were looking for was the final line of output. This can be
solved by adding ${nl} to the end of the output (just as we were
already adding it at the beginning of the output).
Sometimes libvirt is installed on a host that is already using the
network 192.168.122.0/24. If the libvirt-daemon-config-network package
is installed, this creates a conflict, since that package has been
hard-coded to create a virtual network that also uses
192.168.122.0/24. In the past libvirt has attempted to warn of /
remediate this situation by checking for conflicting routes when the
network is started, but it turns out that isn't always useful (for
example in the case that the *other* interface/network creating the
conflict hasn't yet been started at the time libvirtd start its own
networks).
This patch attempts to catch the problem earlier - at install
time. During the %post install script for
libvirt-daemon-config-network, we use a case statement to look through
the output of "ip route show" for a route that exactly matches
192.168.122.0/24, and if found we search for a similar route that
*doesn't* match (e.g. 192.168.124.0/24) (note that the search starts
with "124" instead of 123 because of reports of people already
modifying their L1 host's network to 192.168.123.0/24 in an attempt to
solve exactly the problem we are also trying to solve). When we find
an available route, we just replace all occurrences of "122" in the
default.xml that is being created with the newly found 192.168
subnet. This could obviously be made more complicated - examine the
template defaul.xml to automatically determine the existing network
address and mask rather than hard coding it in the specfile, etc, but
this scripting is simpler and gets the job done as long as we continue
to use 192.168.122.0/24 in the template. (If anyone with mad bash
skillz wants to suggest something to do that, by all means please do).
This is intended to at least "further reduce" occurrence of the
problems detailed in:
https://bugzilla.redhat.com/show_bug.cgi?id=811967
