Instead of including a field in FileTypeInfo struct for the
disk format, rely on the array index matching the format.
Use verify() to assert the correct number of elements in the
array.

* src/util/storage_file.c: remove type field from FileTypeInfo

When QEMU opens a backing store for a QCow2 file, it will
normally auto-probe for the format of the backing store,
rather than assuming it has the same format as the referencing
file. There is a QCow2 extension that allows an explicit format
for the backing store to be embedded in the referencing file.
This closes the auto-probing security hole in QEMU.

This backing store format can be useful for libvirt users
of virStorageFileGetMetadata, so extract this data and report
it.

QEMU does not require disk image backing store files to be in
the same format the file linkee. It will auto-probe the disk
format for the backing store when opening it. If the backing
store was intended to be a raw file this could be a security
hole, because a guest may have written data into its disk that
then makes the backing store look like a qcow2 file. If it can
trick QEMU into thinking the raw file is a qcow2 file, it can
access arbitrary files on the host by adding further backing
store links.

To address this, callers of virStorageFileGetMeta need to be
told of the backing store format. If no format is declared,
they can make a decision whether to allow format probing or
not.

IPtables will seek to preserve the source port unchanged when
doing masquerading, if possible. NFS has a pseudo-security
option where it checks for the source port <= 1023 before
allowing a mount request. If an admin has used this to make the
host OS trusted for mounts, the default iptables behaviour will
potentially allow NAT'd guests access too. This needs to be
stopped.

With this change, the iptables -t nat -L -n -v rules for the
default network will be

Chain POSTROUTING (policy ACCEPT 95 packets, 9163 bytes)
 pkts bytes target     prot opt in     out     source               destination
   14   840 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
   75  5752 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24

* src/network/bridge_driver.c: Add masquerade rules for TCP
  and UDP protocols
* src/util/iptables.c, src/util/iptables.c: Add source port
  mappings for TCP & UDP protocols when masquerading.

This patch removes the individual author names from the libvirtd and virsh
man pages, instead referring to the main AUTHORS file distributed with
libvirt.  This approach is needed, as we can't guarantee unicode support
across all versions of pod2man used with libvirt.

Additionally, this patch includes the libvirtd man page in the spec file
used with "make rpm".  Without this patch "make rpm" is broken.

When printing out size_t, we need to use %zu to make sure it
will continue to compile on both 32-bit and 64-bit platforms.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

Signed-off-by: NChris Lalancette <clalance@redhat.com>

vshMalloc and friends always exit() on allocation failure,
so there is no reason to do checking for NULL in the code
that uses it.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

Nobody was using it anyway.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

There are many naming conventions for partitions associated with a
block device.  Some of the major ones are:

/dev/foo -> /dev/foo1
/dev/foo1 -> /dev/foo1p1
/dev/mapper/foo -> /dev/mapper/foop1
/dev/disk/by-path/foo -> /dev/disk/by-path/foo-part1

The universe of possible conventions isn't clear.  Rather than trying
to understand all possible conventions, this patch divides devices
into two groups, device mapper devices and everything else.  Device
mapper devices seem always to follow the convention of device ->
devicep1; everything else is canonicalized.

dispatch.c requires stdio.h (and stdarg.h), however, currently
dispatch.c implicitly relys on rpc/xdr.h to include stdio.h.
If rpc/xdr.h unxpectedly does not include stdio.h, the compilation
of dispatch.c fails.

This can happen, for example, when portablexdr is installed
under /usr/local; because portablexdr's rpc/xdr.h does not
include stdio.h and gcc looks up it not /usr/include/rpc/xdr.h.

Note that stdarg.h is also included according to man va_start,
although stdio.h seems including it anyway.

* src/uml/uml_driver.c (umlMonitorCommand): Correct flaw that would
cause unconditional "incomplete reply ..." failure, since "nbytes"
was always 0 or 1.

* src/qemu/qemu_driver.c (qemuConnectMonitor): Correct erroneous
parenthesization in two expressions.  Without this fix, failure
to set or clear SELinux security context in the monitor would go
undiagnosed.  Also correct a diagnostic and split some long lines.

A copy and paste error was causing us to dispatch the incorrect
routine. Spotted by Dan Kenigsberg.

This will be used to deserialize the response from a call
to esxVI_SearchDatastore_Task properly.

When comparing a CPU without <model> element, such as

    <cpu>
        <topology sockets='1' cores='1' threads='1'/>
    </cpu>

libvirt would happily crash without warning.

When autodetecting whether XML describes guest or host CPU, the presence
of <arch> element is checked. If it's present, we treat the XML as host
CPU definition. Which is right, since guest CPU definitions do not
contain <arch> element. However, if at the same time the root <cpu>
element contains `match' attribute, we would silently ignore it and
still treat the XML as host CPU. We should rather refuse such invalid
XML.

When a CPU to be compared with host CPU describes a host CPU instead of
a guest CPU, the result is incorrect. This is because instead of
treating additional features in host CPU description as required, they
were treated as if they were mentioned with all possible policies at the
same time.

In case qemu supports -nodefconfig, libvirt adds uses it when launching
new guests. Since this option may affect CPU models supported by qemu,
we need to use it when probing for available models.

pod2man prints the following warning when generating virsh.1:

    tools/virsh.pod:890: Unmatched =back

An indentation mistake meant that a check for return status
was not properly performed in all cases. This could result
in a crash on NULL pointer in a following line.

* src/qemu/qemu_monitor_json.c: Fix check for return status
  when processing JSON for blockstats

Some versions of pod2man do not support the -u flag, so this
can't be used

* daemon/Makefile.am: Remove -u flag from pod2man

A missing return statement in the python binding meant that
the callers could not get the callback ID, and thus not be
able to unregister event callbacks

* python/libvirt-override-virConnect.py: Add missing return
  statement

With gracious thanks to Chris Lalancette for helping knock the
description section into shape.

This addresses BZ #595350

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

This patch adds a new --details option to the virsh vol-list
command, making its output more useful when many luns are
present.

Addresses BZ # 605543

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

Signed-off-by: NChris Lalancette <clalance@redhat.com>

Signed-off-by: NChris Lalancette <clalance@redhat.com>

By specifying <vendor> element in CPU requirements a guest can be
restricted to run only on CPUs by a given vendor. Host CPU vendor is
also specified in capabilities XML.

The vendor is checked when migrating a guest but it's not forced, i.e.,
guests configured without <vendor> element can be freely migrated.

In case the set of CPUs has no features in common, report incompatible
CPUs instead of returning the simplest CPU model with all features
disabled.

All features in the baseline CPU definition were always created with
policy='require' even though an arch driver returned them with different
policy settings.

- configure.ac docs/news.html.in libvirt.spec.in: updated
- po/*/o* : updated or.po and regenerated

This allows the user to give an explicit path to configure

  ./configure --with-vbox=/path/to/virtualbox

instead of having the VirtualBox driver probe a set of possible
paths at runtime. If no explicit path is specified then configure
probes the set of "known" paths.

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

We only use libpciaccess for resolving device product/vendor. If
initializing the library fails (say if using qemu:///session), don't
warn so loudly, and carry on as usual.