Another program gains --help/--version :)

* tools/virt-pki-validate.in: Add option parsing.  Update
documentation to match.
* tools/Makefile.am (virt-pki-validate): Substitute version.
Signed-off-by: NEric Blake <eblake@redhat.com>

We were failing to autoprobe which schema to use for several
top-level XML elements.

* tools/virt-xml-validate.in (TYPE): Recognize <domainsnapshot>,
<filter>, and <secret>.
Signed-off-by: NEric Blake <eblake@redhat.com>

All good tools should have --help and --version output :)

Furthermore, we want to ensure a failed exit if xmllint fails,
or even for 'virt-xml-validate > /dev/full'.

* tools/virt-xml-validate.in: Add option parsing.  Output errors
to stderr.  Update documentation to match.
* tools/Makefile.am (virt-xml-validate): Substitute version.
Signed-off-by: NEric Blake <eblake@redhat.com>

From: Dario Faggioli <dario.faggioli@citrix.com>

Starting from Xen 4.2, libxl has all the bits and pieces in place
for retrieving an adequate amount of information about the host
NUMA topology. It is therefore possible, after a bit of shuffling,
to arrange those information in the way libvirt wants to present
them to the outside world.

Therefore, with this patch, the <topology> section of the host
capabilities is properly populated, when running on Xen, so that
we can figure out whether or not we're running on a NUMA host,
and what its characteristics are.

[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// capabilities
<capabilities>
  <host>
    <cpu>
    ....
    <topology>
      <cells num='2'>
        <cell id='0'>
          <memory unit='KiB'>6291456</memory>
          <cpus num='8'>
            <cpu id='0' socket_id='1' core_id='0' siblings='0-1'/>
            <cpu id='1' socket_id='1' core_id='0' siblings='0-1'/>
            <cpu id='2' socket_id='1' core_id='1' siblings='2-3'/>
            <cpu id='3' socket_id='1' core_id='1' siblings='2-3'/>
            <cpu id='4' socket_id='1' core_id='9' siblings='4-5'/>
            <cpu id='5' socket_id='1' core_id='9' siblings='4-5'/>
            <cpu id='6' socket_id='1' core_id='10' siblings='6-7'/>
            <cpu id='7' socket_id='1' core_id='10' siblings='6-7'/>
          </cpus>
        </cell>
        <cell id='1'>
          <memory unit='KiB'>6881280</memory>
          <cpus num='8'>
            <cpu id='8' socket_id='0' core_id='0' siblings='8-9'/>
            <cpu id='9' socket_id='0' core_id='0' siblings='8-9'/>
            <cpu id='10' socket_id='0' core_id='1' siblings='10-11'/>
            <cpu id='11' socket_id='0' core_id='1' siblings='10-11'/>
            <cpu id='12' socket_id='0' core_id='9' siblings='12-13'/>
            <cpu id='13' socket_id='0' core_id='9' siblings='12-13'/>
            <cpu id='14' socket_id='0' core_id='10' siblings='14-15'/>
            <cpu id='15' socket_id='0' core_id='10' siblings='14-15'/>
          </cpus>
        </cell>
      </cells>
    </topology>
  </host>
  ....

When the daemon is compiled with firewalld support but the DBus message
bus isn't started in the system, the initialization of the nwfilter
driver fails even if there are fallback options.

On hosts that don't have the DBus service running or installed the new
systemd cgroups code failed with hard error instead of falling back to
"manual" cgroup creation.

Use the new helper to check for the system bus and use the fallback code
in case it isn't available.

Some systems may not use DBus in their system. Add a method to check if
the system bus is available that doesn't print error messages so that
code can later check for this condition and use an alternative approach.

Coverity reported a memleak in the test added in 7efd5fd1. In case
the code will be broken and the code will actually parse a faulty bitmap
the resulting pointer would be leaked. Free it although that shouldn't
ever happen.

Each new VM requires a new connection from libvirtd to virtlockd.
The default max clients limit in virtlockd of 20 is thus woefully
insufficient. virtlockd sockets are only accessible to matching
users, so there is no security need for such a tight limit. Make
it configurable and default to 1024.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In one of my previous patches I am removing the hard_limit heuristic to
guess the correct value if none set. However, it turned out, this limit
is hard to guess even for users. We should advise them to not set the
limit as their domains may be OOM killed. Sigh.

This function is to guess the correct limit for maximal memory
usage by qemu for given domain. This can never be guessed
correctly, not to mention all the pains and sleepless nights this
code has caused. Once somebody discovers algorithm to solve the
Halting Problem, we can compute the limit algorithmically. But
till then, this code should never see the light of the release
again.

One has to refresh the pool to get the correct pool info after
adding/removing/resizing a volume, this updates the pool metadata
(allocation, available) after those operation are done.

Similar to how other objects arrange their parse APIs. This will be
used by the test driver.

Right now things are split a bit between parsing from a relative file
path or parsing from inline XML. Unify it. This will simplify upcoming
bits.

Passing virConnectPtr is redundant, just pass testConnPtr and simplify
certain callers.

The function that parses custom driver XML was getting pretty unruly,
split the object parsing into their own functions. Rename some variables
to be consistent across each function. This should be functionally
identical.

Currently the virConnectBaselineCPU API does not expose the CPU features
that are part of the CPU's model.  This patch adds a new flag,
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, that causes the API to explicitly
list all features that are part of that model.
Signed-off-by: NDon Dugger <donald.d.dugger@intel.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Rather than inlining gl_WARN_ADD loads of time, we can shave about
17k size off of the configure script by delaying it to a cleanup
shell loop.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Track a
list of things to check, rather than inlining multiple checks.
Signed-off-by: NEric Blake <eblake@redhat.com>

Cleanup the libxl capabilities code to be a bit more extensible,
splitting out the creation of host and guest capabilities.  This
should make it easier to implement additional capabilities in the
future, such as NUMA topology reporting.

Feedback from the polkit developers indicates that the
"_detail_XXXX" attributes are a private implementation
detail. Our examples should be recommending use of the
"action.lookup('XXX')" method instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Previous patch fixed an issue where, when parsing a bitmap from the
string, the bounds of the bitmap weren't checked. That flaw resulted into
crashes. This test tests that case to avoid it in the future.

The virBitmapParse function was calling virBitmapIsSet() function that
requires the caller to check the bounds of the bitmap without checking
them. This resulted into crashes when parsing a bitmap string that was
exceeding the bounds used as argument.

This patch refactors the function to use virBitmapSetBit without
checking if the bit is set (this function does the checks internally)
and then counts the bits in the bitmap afterwards (instead of keeping
track while parsing the string).

This patch also changes the "parse_error" label to a more common
"error".

The refactor should also get rid of the need to call sa_assert on the
returned variable as the callpath should allow coverity to infer the
possible return values.

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

Thanks to Alex Jia for tracking down the issue. This issue is introduced
by commit 0fc89098.

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

==1349431== 8 bytes in 1 blocks are definitely lost in loss record 11 of 760
==1349431==    at 0x4C2A554: calloc (vg_replace_malloc.c:593)
==1349431==    by 0x4E9AA3E: virAllocN (in /usr/lib64/libvirt.so.0.1001.1)
==1349431==    by 0x4EF28C4: virXPathNodeSet (in /usr/lib64/libvirt.so.0.1001.1)
==1349431==    by 0x130B83: cmdCPUBaseline (in /usr/bin/virsh)
==1349431==    by 0x12C608: vshCommandRun (in /usr/bin/virsh)
==1349431==    by 0x12889A: main (in /usr/bin/virsh)

Gnulib recently patched gcc warning detection so that it does
not treat things like -Wno-unused-command-line-argument as
supported in gcc (treating it as supported merely resulted in
extra verbosity when an actual compile error occurred).  It
has also improved bootstrap to work with less hassle on OpenBSD.

* .gnulib: Update to latest, in part for bootstrap and warnings
improvements.
* bootstrap: Resync from gnulib.
Signed-off-by: NEric Blake <eblake@redhat.com>

I noticed that in a fresh checkout, autogen.sh generated the
following output, but continued on with execution:

autoreconf: running: automake --add-missing --copy --force-missing
gnulib/tests/Makefile.am:28: TESTS was already defined in condition TRUE, which includes condition WITH_EXPENSIVE_TESTS ...
gnulib/tests/gnulib.mk:28: ... `TESTS' previously defined here
gnulib/tests/Makefile.am:19:   `gnulib/tests/gnulib.mk' included from here

and after the run, line 28 of gnulib.mk lists GNULIB_TESTS, not TESTS.
After more investigation, I found that it is because gnulib bootstrap
provides two hooks, one before automake, and the other after; we used
the one that ran after, and were then rerunning automake ourselves;
and the warning was from the first run.  But a manual second run is
pointless if we use the right hook in the first place.

The wrong function name has been latent since commit 38c9440a, and we
tried to work around it in commit 6cbab7c1, but it took commit 70363ea9
to finally change output enough for me to realize the root cause.

* bootstrap.conf (bootstrap_epilogue): Rename...
(bootstrap_post_import_hook): ...so that it gets run before automake.
Signed-off-by: NEric Blake <eblake@redhat.com>

* src/util/virnetdevvportprofile.c: Fix typo.
* src/conf/domain_conf.c: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

There is a potential leak of a newly created libxlDomainObjPrivate
when subsequent allocation of the object's chrdev field fails.
Unref the object on such an error so that it is properly disposed.

When undefining a domain with storage when the volume isn't managed by
libvirt the name and path strings weren't freed properly.

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

This restores the error message when QMP probing is not used.

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

As per HACKING, remove some unneeded curly braces in the
libxl driver.

commit 14e7e0ae adds the support for
crash events.

Solves: https://bugzilla.redhat.com/show_bug.cgi?id=994317Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

This resolves the issue that prompted the filing of

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

(although the request there is for something much larger and more
general than this patch).

commit f3868259 disabled the
forwarding to upstream DNS servers of unresolved DNS requests for
names that had no domain, but were just simple host names (no "."
character anywhere in the name). While this behavior is frowned upon
by DNS root servers (that's why it was changed in libvirt), it is
convenient in some cases, and since dnsmasq can be configured to allow
it, it must not be strictly forbidden.

This patch restores the old behavior, but since it is usually
undesirable, restoring it requires specification of a new option in
the network config. Adding the attribute "forwardPlainNames='yes'" to
the <dns> elemnt does the trick - when that attribute is added to a
network config, any simple hostnames that can't be resolved by the
network's dnsmasq instance will be forwarded to the DNS servers listed
in the host's /etc/resolv.conf for an attempt at resolution (just as
any FQDN would be forwarded).

When that attribute *isn't* specified, unresolved simple names will
*not* be forwarded to the upstream DNS server - this is the default
behavior.

and wrap some long lines
Signed-off-by: NEric Blake <eblake@redhat.com>

Power7+ and Power8 are supported in QEMU, so it needs to define CPUs
in libvirt to support them.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

The description for <permissions> was copied from the storage volume
section to the storage pool section, but the semantics are different:
1. Currently only the "dir", "fs" and "netfs" storage pools use it.
2. They use it only to build the final directory.
3. A default for the storage volumes can't be set.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

The Linux build revealed another missing direct link target, this time
against selinux libs:

    http://honk.sigxcpu.org:8001/view/libvirt/job/libvirt-build-debian-sid-amd64/9/console