Add virDomainObjGetShortName() and use it.  For now that's used in one
place, but we should expose it so that future patches can use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Introduced by commit 15ad2ecf.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45

However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:

http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html

Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely

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

If you compile a client --without-polkit, and connect to a URI that needs
polkit auth, the connection will fail with:

$ ./tools/virsh --connect qemu+ssh://crobinso@machine/system
error: failed to connect to the hypervisor
error: authentication failed: unsupported authentication type 2

This is because the client side portion of the polkit handling is
compiled out. However, nothing polkit specific is actually required
of the client.

Fix that error by unconditionally compiling the basic polkit client
handling.

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

Commit 1d440008 added some code that was not indented properly
and broke syntax-check. Fix it.

If libvirt-daemon-config-network is installed while libvirtd is already
running, the daemon doesn't notice the network. Users then have to
manually restart libvirtd (or reboot) to pick up the network.

Instead let's trigger a daemon restart when the package is first installed.
Then the default network is available immediately if libvirtd was already
running.

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

The hex range already tried to allow for it, but it wasn't using
the correct XML hex syntax. Fix it, and test it

Since commit 9b77ce63 we create a .in file while building all
man pages, including those in the tools/ directory; update the
ignore patterns to take this change into account.

The new ignore patterns are generic enough that we can get rid of
a few existing ones as well.

All top-level functions have been moved to this class.

On top of that, the app.warning() method has been defined,
so that calls to it - already present in rebuild() - can
actually succeed.

This method is used in eg. index.merge(), but is not defined
anywhere. The implementation has been copied from docBuilder.

Since commit d195cffa, both $(srcdir) and $(abs_builddir)
are passed to the apibuild.py script; however, since the
former is a relative path and the latter an absolute one, the
script might not be able to detect whether they point to the
same location.

Pass both as relative paths to avoid the issue.

Change 'ephemeral' to 'isephemeral' and 'private' to 'isprivate' since
both are bools.

Introduce the final accessor's to _virSecretObject data and move the
structure from virsecretobj.h to virsecretobj.c

The virSecretObjSetValue logic will handle setting both the secret
value and the value_size. Some slight adjustments to the error path
over what was in secretSetValue were made.

Additionally, a slight logic change in secretGetValue where we'll
check for the internalFlags and error out before checking for
and erroring out for a NULL secret->value. That way, it won't be
obvious to anyone that the secret value wasn't set rather they'll
just know they cannot get the secret value since it's private.

Introduce fetch and set accessor to the secretObj->def field for usage
by the driver to avoid the driver needing to know the format of virSecretObj

Move and rename the secretRewriteFile, secretSaveDef, and secretSaveValue
from secret_driver to virsecretobj

Need to make some slight adjustments since the secretSave* functions
called secretEnsureDirectory, but otherwise mostly just a move of code.

Move and rename secretDeleteSaved from secret_driver into virsecretobj and
split it up into two parts since there is error path code that looks to
just delete the secret data file

Move to secret_conf.c and rename to virSecretLoadAllConfigs. Also includes
moving/renaming the supporting virSecretLoad, virSecretLoadValue, and
virSecretLoadValidateUUID.

This patch replaces most of the guts of secret_driver.c with recently
added secret_conf.c APIs in order manage secret lists and objects
using the hashed virSecretObjList* lookup API's.

Add function to return counted listed of uuids to from the hashed secrets
object list. This will replace the guts of secretConnectListSecrets.

Add function to return a "match" filtered list of secret objects. This
function replaces the guts of secretConnectListAllSecrets.

Need to also move and make global virSecretUsageIDForDef since it'll
be used by both secret_driver.c and secret_conf.c

Add function to count the hashed secret obj list with filters. This
will replace the guts of secret_driver's secretConnectNumOfSecrets.

Add the functions to add/remove elements from the hashed secret obj list.
These will replace secret_driver functions secretAssignDef and secretObjRemove.

The virSecretObjListAddLocked will perform the necessary lookups and
decide whether to replace an existing hash entry or create a new one.
This includes setting up the configPath and base64Path as well as being
able to support the caller's need to restore from a previous definition
in case something goes wrong in the caller.

Move the driver specific secretUsageIDForDef into secret_conf.c. It could
be more of a general purpose API.

New API's including unlocked and Locked versions in order to be able
to use in either manner.

Support for searching hash object lists instead of linked lists will
replace existing secret_driver functions secretFindByUUID and
secretFindByUsage

Move virSecretObj from secret_driver.c to virsecretobj.h

To support being able to create a hashed secrets list, move the
virSecretObj to virsecretobj.h so that the code can at least find
the definition.

This should be a temporary situation while the virsecretobj.c code
is patched in order to support a hashed secret object while still
having the linked list support in secret_driver.c. Eventually, the
goal is to move the virSecretObj into virsecretobj.c, although it
is notable that the existing model from which virSecretObj was
derived has virDomainObj in src/conf/domain_conf.h and virNetworkObj
in src/conf/network_conf.h, so virSecretObj wouldn't be unique if
it were to remain in virsecretobj.h  Still adding accessors to fetch
and store hashed object data will be the end goal.

Add definitions and infrastucture in virsecretobj.c to create and
handle a hashed virSecretObj and virSecretObjList including the class,
object, lock setup, and disposal API's. Nothing will call these yet.

This infrastructure will replace the forward linked list logic
within the secret_driver, eventually.

Our distcheck is broken. Well, it works but only by pure chance.
When wireshark plugin is enabled, we try to query which path
should the plugin be installed into. Firstly, we try to ask
pkg-config as some releases of wireshark already sets
corresponding variable in their pkg-config files. However, if we
obtained no value from there we try to construct the path on our
own. Based on our observations it usually is:
$libdir/wireshark/plugins/$version/.
Now, the problem is in the way we are deciding whether we have
obtained the plugin directory from pkg-config or not. Simply
said, we are checking wrong variable. The variable we are
checking has never been set, thus in our test is empty and
therefore we will always construct the plugin dir path on our
own, regardless of its presence in the pkg-config file.
To make things worse, after fixing this problem, VPATH build was
broken as it now tried to install plugin into correct directory.
Yes, this is problem, because --prefix was not honoured and
everything but the plugin was installed into given prefix. I've
managed to resolve this issue by replacing plugin dir prefix with
our own. So when doing regular installation (our prefix ==
wireshark prefix), nothing changes. When doing VPATH build &
installation plugin is installed into correctly prefixed dir.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We do have something similar for installing init system files.
Basically I'm trying to avoid the following warning produced by
automake:

tools/Makefile.am:429: warning: uninstall-local was already defined in condition TRUE, which includes condition WITH_BSD_NSS ...
tools/Makefile.am:292: ... 'uninstall-local' previously defined here
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This target has been disabled historically for whatever reason.
Now that we do uninstall properly enable the test again.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function - in contrast with qemuBuildCommandLine - merely
constructs our internal command representation of a domain. This
is then later compared against expected output. Or, this function
is used also in virConnectDomainXMLToNative(). But due to a copy
paste error this function, just like its image - has @forceFips
argument that if enabled forces FIPS, otherwise mimics FIPS state
in the host. If FIPS is enabled or forced the generated command
line is different to state in which FIPS is disabled. Problem is,
while this could be desired in the virConnectDomainXMLToNative()
case, this is undesirable in the test suite as it will produce
unpredicted results.
Solution to this is to rename argument to @enableFips to
specifically tell whether we expect command line to be build in
either of fashions and make virConnectDomainXMLToNative()
implementation fetch FIPS state and pass it to
qemuProcessCreatePretendCmd().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This error message was too specific, based on the incorrect assumption
that any error was cause by auto-added bridges:

  failed to create PCI bridge on bus 2: too many devices
  with fixed addresses

In practice you can't know if a bridge with an index <= the bus it's
connecting to was added automatically, or if it was a mistake in
explicit config, and the auto-add problem is going to be dealt with in
a different way in an upcoming patch. The new message is this:

  PCI Controller at index 1 (0x01) has "
  bus='0x02', but bus must be <= index

(note that index is given in both decimal and hex because it is
formatted as decimal in the XML, but bus is formatted as hex, and
displaying the hex value of index makes it easier to see the problem
when index > 9 (which will often be the case with PCIe, since most
controllers only have a single port, not 32 slots as with standard
PCI)).

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

Use L<> instead of C<> for URLs and man pages.

Format the text properly.

podchecker(1) complained about these, eg.

  *** WARNING: Verbatim paragraph in NAME section at line 3 in
               file tools/virt-host-validate.pod

No need to special-case this one: we can add it to EXTRA_DIST so
that it will be shipped in any case, and if WITH_LOGIN_SHELL
happens to be enabled we mark it for installation as well.

We can't use eg. @sysconfdir@ directly in the .pod file, because
pod2man(1) will interpret that as a variable name and format it
accordingly.

Instead, we use eg. SYSCONFDIR and use a subsequent sed(1) call
to turn it into the expected @sysconfdir@.

All $(MANINFILES) should be deleted on distclean.

Define $(PODFILES) and $(MANINFILES) so that adding a new man
page only requires changes in a few, well defined spots.

The generated man pages may contain information that depend on
the build configuration, so they should not be shipped but
rather always built on the user's machine.

After this commit, all man pages are generated using the same two
steps:

  1. Process a source $command.pod file with pod2man(1) to obtain
     a valid man page in $command.$section.in

  2. Process $command.$section.in with sed(1) to obtain the final
     man page in $command.$section