rpc: fix build failure with older dbus

RHEL 6.3 uses dbus-devel-1.2.24, which lacked support for the
DBUS_TYPE_UNIX_FD define (contrast with Fedora 18 using 1.6.8).
But since it is an older dbus, it also lacks support for shutdown
inhibitions as provided by newer systemd.

Compilation failure introduced in commit 31330926.

* src/rpc/virnetserver.c (virNetServerAddShutdownInhibition):
Compile out if dbus is too old.
qemu: nicer error message if live disk snapshot unsupported

Without this patch, attempts to create a disk snapshot when qemu
is too old results in a cryptic message:

virsh # snapshot-create 23 --disk-only
error: operation failed: Failed to take snapshot: unknown command: 'snapshot_blkdev'

Now it reports:

virsh # snapshot-create 23 --disk-only
error: unsupported configuration: live disk snapshot not supported with this QEMU binary

All versions of qemu that support live disk snapshot also support
QMP (basically upstream qemu 1.1 and later, and backports to RHEL 6.2).

* src/qemu/qemu_capabilities.h (QEMU_CAPS_DISK_SNAPSHOT): New
capability.
* src/qemu/qemu_capabilities.c (qemuCaps): Track it.
(qemuCapsProbeQMPCommands): Set it.
* src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive): Use
it.
* src/qemu/qemu_monitor.c (qemuMonitorDiskSnapshot): Simplify.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskSnapshot):
Likewise.
* src/qemu/qemu_monitor_text.h (qemuMonitorTextDiskSnapshot):
Delete.
* src/qemu/qemu_monitor_text.c (qemuMonitorTextDiskSnapshot):
Likewise.
qemu: improve error for failed JSON commands

Only one error in qemu_monitor was already using the relatively
new OPERATION_UNSUPPORTED error, even though it is a better fit
for all of the messages related to options that are unsupported
due to the version of qemu in use rather than due to a user's
XML or .conf file choice.  Suggested by Osier Yang.

* src/qemu/qemu_monitor.c (qemuMonitorSendFileHandle)
(qemuMonitorAddHostNetwork, qemuMonitorRemoveHostNetwork)
(qemuMonitorAttachDrive, qemuMonitorDiskSnapshot)
(qemuMonitorDriveMirror, qemuMonitorTransaction)
(qemuMonitorBlockCommit, qemuMonitorDrivePivot)
(qemuMonitorBlockJob, qemuMonitorSystemWakeup)
(qemuMonitorGetVersion, qemuMonitorGetMachines)
(qemuMonitorGetCPUDefinitions, qemuMonitorGetCommands)
(qemuMonitorGetEvents, qemuMonitorGetKVMState)
(qemuMonitorGetObjectTypes, qemuMonitorGetObjectProps)
(qemuMonitorGetTargetArch): Use better error category.
storage: Remove the redundant white lines

Pushed under trivial rule.
qemu: Simplify the code

"disk" is initialized to "dev->data.disk" in the beginning of the
function.
systemd: require dbus service

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

The initscript and upstart services depend on dbus starting
before libvirtd.  When we first wrote the systemd script, we
tried to do the same, but we depended on dbus.target (which
does not exist) in comparison to network.target (which does
exist), so we removed that in commit 4c7973e.  But we still
need dbus up and running first, especially now that we want
to support shutdown inhibition via dbus (whereas we originally
needed dbus only for firewall control).

http://www.freedesktop.org/software/systemd/man/systemd.target.html
explains how a target (such as network.target) is just a collection
of common services bundled together, and why we want network.target
but dbus.service.

* daemon/libvirtd.service.in (Unit): Depend on dbus starting
first.
spec: require dbus-daemon when using libvirtd in Fedora

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

In older Fedora, the spec file for libivrt depended on avahi, which
included avahi-daemon, which in turn depended on dbus.  But now that
avahi libs and avahi-daemon are (correctly) in separate pacakges,
and since we REALLY don't want a mandatory dependency on avahi-daemon,
and considering that our init scripts require the messagebus service
from dbus, we need to explicitly require dbus ourselves.

* libvirt.spec.in (Requires): Add dbus for libvirt-daemon.
qemu: Fix error code when attaching existing device

An attempt to attach device that is already attached to a domain results
in the following error:

virsh # attach-device rhel6 pci2 --persistent
error: Failed to attach device from pci2
error: invalid argument: device is already in the domain configuration

The "invalid argument" error code looks wrong, we usually use "operation
invalid" when the action cannot be done in current state.
qemu: Don't free PCI device if adding it to activePciHostdevs fails

The device is still referenced from pcidevs and freeing it would leave
an invalid pointer there.
util: Slightly refactor PCI list functions

In order to be able to steal PCI device by its index in the list.
qemu: Fix memory (and FD) leak on PCI device detach

Unmanaged PCI devices were only leaked if pciDeviceListAdd failed but
managed devices were always leaked. And leaking PCI device is likely to
leave PCI config file descriptor open. This patch fixes
qemuReattachPciDevice to either free the PCI device or add it to the
inactivePciHostdevs list.
util: Do not keep PCI device config file open

Directly open and close PCI config file in the APIs that need it rather
than keeping the file open for the whole life of PCI device structure.
pci: Fix building of 32bit PCI command array

The pciWrite32 function assembled the array of data to be written to the
fd with a bad offset on the last byte. This issue was probably caused by
a typo (14, 24).
remote: Avoid the thread race condition

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

Since the virConnect object is not locked wholely when doing
virConenctDispose, a thread can get the lock and thus might
cause the race.

Detected by valgrind:

==23687== Invalid read of size 4
==23687==    at 0x38BAA091EC: pthread_mutex_lock (pthread_mutex_lock.c:61)
==23687==    by 0x3FBA919E36: remoteClientCloseFunc (remote_driver.c:337)
==23687==    by 0x3FBA936BF2: virNetClientCloseLocked (virnetclient.c:688)
==23687==    by 0x3FBA9390D8: virNetClientIncomingEvent (virnetclient.c:1859)
==23687==    by 0x3FBA851AAE: virEventPollRunOnce (event_poll.c:485)
==23687==    by 0x3FBA850846: virEventRunDefaultImpl (event.c:247)
==23687==    by 0x40CD61: vshEventLoop (virsh.c:2128)
==23687==    by 0x3FBA8626F8: virThreadHelper (threads-pthread.c:161)
==23687==    by 0x38BAA077F0: start_thread (pthread_create.c:301)
==23687==    by 0x33F68E570C: clone (clone.S:115)
==23687==  Address 0x4ca94e0 is 144 bytes inside a block of size 312 free'd
==23687==    at 0x4A0595D: free (vg_replace_malloc.c:366)
==23687==    by 0x3FBA8588B8: virFree (memory.c:309)
==23687==    by 0x3FBA86AAFC: virObjectUnref (virobject.c:145)
==23687==    by 0x3FBA8EA767: virConnectClose (libvirt.c:1458)
==23687==    by 0x40C8B8: vshDeinit (virsh.c:2584)
==23687==    by 0x41071E: main (virsh.c:3022)

The above race is caused by the eventLoop thread tries to handle
the net client event by calling the callback set by:
    virNetClientSetCloseCallback(priv->client,
                                 remoteClientCloseFunc,
                                 conn, NULL);

I.E. remoteClientCloseFunc, which lock/unlock the virConnect object.

This patch is to fix the bug by setting the callback to NULL when
doRemoteClose.
storage: Error out earlier if the volume target path already exists

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

It's odd to fall through to buildVol, and the existed file is
removed when buildVol fails. This checks if the volume target
path already exists in createVol. The reason for not using
error like "Volume already exists" is that there isn't volume
maintained by libvirt for the path until a operation like
pool-refresh, using error like that will just cause confusion.
network: allow guest to guest IPv6 without gateway definition

This patch adds the capability for virtual guests to do IPv6
communication via a virtual network interface with no IPv6 (gateway)
addresses specified.  This capability has always been enabled by
default for IPv4, but disabled for IPv6 for security concerns, and
because it requires the ip6tables command to be operational (which
isn't the case on a system with the ipv6 module completely disabled).

This patch adds a new attribute "ipv6" at the toplevel of a <network>
object.  If ipv6='yes', the extra ip6tables rules required to permite
inter-guest communications are added when the network is started. If
it is 'no', or not present, those rules will not be added; thus the
default behavior doesn't change, so there should be no compatibility
issues with any existing installations.

Note that virtual guests cannot communication with the virtualization
host via this interface, because the following kernel tunable has
been set:

   net.ipv6.conf.<bridge_interface_name>.disable_ipv6 = 1

This assures that the bridge interface will not have an IPv6
link-local (fe80::) address.

To control this behavior so that it is not enabled by default, the parameter
ipv6='yes' on the <network> statement has been added.

Documentation related to this patch has been updated.
The network schema has also been updated.
network: prevent a few invalid configuration combinations

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=767057

It was possible to define a network with <forward mode='bridge'> that
had both a bridge device and a forward device defined. These two are
mutually exclusive by definition (if you are using a bridge device,
then this is a host bridge, and if you have a forward dev defined,
this is using macvtap). It was also possible to put <ip>, <dns>, and
<domain> elements in this definition, although those aren't supported
by the current driver (although it's conceivable that some other
driver might support that).

The items that are invalid by definition, are now checked in the XML
parser (since they will definitely *always* be wrong), and the others
are checked in networkValidate() in the network driver (since, as
mentioned, it's possible that some other network driver, or even this
one, could some day support setting those).
dnsmasq: Fix parsing of the version number

If the debugging is enabled, the virCommand subsystem catches debug
messages in the command output as well. In that case, we can't assume
the string corresponding to command's stdout will start with specific
prefix. But the prefix can be moved deeper in the string. This bug
shows itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000:
18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version
doesn't start with expected "Dnsmasq version " string but a libvirt
debug output.
dnsmasq: Fix parsing of the version number

If debugging is enabled, the debug messages are sent to stderr.
Moreover, if a command has catching of stderr set, the messages
gets mixed with stdout output (assuming both outputs are stored
in the same variable). The resulting string then doesn't
necessarily have to start with desired prefix then. This bug
exposes itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06
11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version doesn't
start with expected "Dnsmasq version " string but a libvirt debug
output.
util: Don't fail virGetUserIDByName when user not found

virGetUserIDByName is documented as returning 1 if the username
cannot be found. getpwnam_r is documented as returning:
« 0 or ENOENT or ESRCH or EBADF or EPERM or ...  The given name
or uid was not found. »
 and that:
« The formulation given above under "RETURN VALUE" is from POSIX.1-2001.
It  does  not  call  "not  found"  an error, hence does not specify what
value errno might have in this situation.  But that makes it impossible to
recognize errors.  One might argue that according to POSIX errno should be
left unchanged if an entry is not found.  Experiments on various UNIX-like
systems shows that lots of different values occur in this situation: 0,
ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others. »

virGetUserIDByName returns an error when the return value of getpwnam_r
is non-0. However on my RHEL system, getpwnam_r returns ENOENT when the
requested user cannot be found, which then causes virGetUserID not
to behave as documented (it returns an error instead of falling back
to parsing the passed-in value as an uid).

This commit makes virGetUserIDByName only report an error when errno
is set to one of the values in the posix description of getpwnam_r
(which are the same as the ones described in the manpage on my system).