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.

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

Format the text properly.

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@.

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

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

No file should be created inside $(srcdir) during build.

QEMU_BLOCK_IOTUNE_MAX is the maximum inclusively, so let's modify the
message so it makes sense.

https://bugzilla.redhat.com/show_bug.cgi?id=1329041Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We presently don't give any indication if the VirtualBox version
isn't in our support whitelist.

The values are currently limited to LLONG_MAX which causes some
problems.  QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages.  Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).

Since values out of the new specified range do not overflow anything,
change the type of error as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf

Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing

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

According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:

 dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0

The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.

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

Additionally avoid initializing it after being calloced.

Additionally switch to using a common temp variable for the xml
elements.

Use a single temporary variable instead shortening the code.

Rather than checking individual fields in dubious places extract them to
a central point.

FreeBSD's sed(1) doesn't support using "\n" to insert a newline,
so the installed default.xml file ends up containing a literal
"n" between tags; to work around this problem, add a tr(1)
invocation as suggested by the sed FAQ[1].

[1] http://sed.sourceforge.net/sedfaq4.html (4.1 c)

After 434de30d the status values are prefixed VIR_NET_
rather than REMOTE_.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The stream serial number is the serial number of the RPC call
that initiated a data transfer. And as such can never be
negative. Moreover, when looking up internal state for a stream,
the serial numbers are compared. But hey, the serial number in
message header is unsigned too!
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

According to the autoconf manual, using '$(LN_S) -f' is not
portable; remove the target explicitly beforehand to work around
this limitation.

Adjust some slightly awkward indentation while at it.