The KVM build of QEMU includs the thread ID of each vCPU in the
'query-cpus' output. This is required for pinning guests to
particular host CPUs

* src/qemu/qemu_monitor_json.c: Extract 'thread_id' from CPU info

* src/util/json.c, src/util/json.h: Declare returned strings
  to be const
* src/qemu/qemu_monitor.c: Wire up JSON mode for qemuMonitorGetPtyPaths
* src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h: Fix
  const correctness. Add missing error message in the function
  qemuMonitorJSONGetAllPCIAddresses. Add implementation of the
  qemuMonitorGetPtyPaths function calling 'query-chardev'.

Two files were using functions from <sys/stat.h> but not including
in. Most of the time they got this automatically via another header,
but certain build flag combinations can reveal the problem

* src/lxc/lxc_container.c, src/node_device/node_device_linux_sysfs.c:
  Add <sys/stat.h>

The <console> tag is supposed to result in addition of a single
<serial> device for HVM guests. The 'targetType' attribute was
missing though causing the compatibility code to add a second
<console> device

* src/conf/domain_conf.c: Set targetType for serial device

* src/util/hostusb.c (usbGetDevice): Free "dev" when returning NULL.

* src/qemu/qemu_monitor_text.c (qemuMonitorCommandWithHandler):
Always free *reply, upon failure.

* src/util/hostusb.c (usbFindBusByVendor): Don't leak a DIR buffer
and file descriptor.

* configure.ac: reanmed configura.in, use AC_CONFIG_HEADERS instead of
  AM_CONFIG_HEADER

When libvirtd shuts down, it places a <state/> tag in the XML
state file it writes out for guests with PCI passthrough
devices.  For devices that are attached at bootup time, the
state tag is empty.  However, at libvirtd startup time, it
ignores anything with a <state/> tag in the XML, effectively
hiding the guest.
This patch remove the check for VIR_DOMAIN_XML_INTERNAL_STATUS
when parsing the XML.
* src/conf/domain_conf.c: remove VIR_DOMAIN_XML_INTERNAL_STATUS
  flag check in virDomainHostdevSubsysPciDefParseXML()

Certain hypervisors (like qemu/kvm) map the PCI bar(s) on
the host when doing device passthrough.  This can lead to a race
condition where the hypervisor is still cleaning up the device while
libvirt is trying to re-attach it to the host device driver.  To avoid
this situation, we look through /proc/iomem, and if the hypervisor is
still holding onto the bar (denoted by the string in the matcher variable),
then we can wait around a bit for that to clear up.

v2: Thanks to review by DV, make sure we wait the full timeout per-device
Signed-off-by: NChris Lalancette <clalance@redhat.com>

The patches to add ACS checking to PCI device passthrough
introduced a bug.  With the current code, if you try to
passthrough a device on the root bus (i.e. bus 0), then
it denies the passthrough.  This is because the code in
pciDeviceIsBehindSwitchLackingACS() to check for a parent
device doesn't take into account the possibility of the
root bus.  If we are on the root bus, it means we
legitimately can't find a parent, and it also means that
we don't have to worry about whether ACS is enabled.
Therefore return 0 (indicating we don't lack ACS) from
pciDeviceIsBehindSwitchLackingACS().
Signed-off-by: NChris Lalancette <clalance@redhat.com>

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

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

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

adds a new python API call for retrieving the running
hypervisor version used by a connection: virConnectGetVersion

* python/generator.py: skip virConnectGetVersion from autogenerated
* python/libvirt-override-api.xml python/libvirt-override.c: define
  direct native bindings

* src/security/security_apparmor.c: unused variable in
  AppArmorSetSecurityAllLabel and unused parameter in
  AppArmorReleaseSecurityLabel

* docs/contact.html.in: Document new users mailing list

Fix a small problem with the qemu memory stats parsing algorithm.  If qemu
reports a stat that libvirt does not recognize, skip past it so parsing can
continue.  This corrects a potential infinite loop in the parsing code that can
only be triggered if new statistics are added to qemu.

* src/qemu/qemu_monitor_text.c: qemuMonitorParseExtraBalloonInfo add a
  skip for extra ','

* src/node_device/node_device_linux_sysfs.c: open_wwn_file() the
  VIR_ERROR resllay should be just a VIR_DEBUG

* src/node_device/node_device_udev.c: udevSetupSystemDev() only print the
  error message if lookup failed in both DMI_DEVPATH and DMI_DEVPATH_FALLBACK

* src/util/uuid.c: extend virUUIDParse to allow leading and trailing
  spaces in UUIDs

* tests/Makefile.am (qemuhelpdata): Add qemu-0.12.1.

* src/qemu/qemu_conf.c (qemuBuildDriveStr): Use "%s".
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONGetGuestPCIAddress):
(qemuMonitorJSONGetGuestDriveAddress): Likewise.

* src/conf/domain_conf.c (virDomainDeviceInfoParseXML): Use "%s".

The loop looking for the controller associated with a SCI drive had
an off by one, causing it to miss the last controller.

* src/qemu/qemu_driver.c: Fix off-by-1 in searching for SCSI
  drive hotplug

The hotplug code in QEMU was leaking memory because although the
inner device object was being moved into the main virDomainDefPtr
config object, the outer container virDomainDeviceDefPtr was not.

 * src/qemu/qemu_driver.c: Clarify code to show that the inner
   device object is owned by the main domain config upon
   successfull attach.

Add the ability to turn off dynamic management of file permissions
for libvirt guests.

* qemu/libvirtd_qemu.aug: Support 'dynamic_ownership' flag
* qemu/qemu.conf: Document 'dynamic_ownership' flag.
* qemu/qemu_conf.c: Load 'dynamic_ownership' flag
* qemu/test_libvirtd_qemu.aug: Test 'dynamic_ownership' flag

The hotplug code was not correctly invoking the security driver
in error paths. If a hotplug attempt failed, the device would
be left with VM permissions applied, rather than restored to the
original permissions. Also, a CDROM media that is ejected was
not restored to original permissions. Finally there was a bogus
call to set hostdev permissions in the hostdev unplug code

* qemu/qemu_driver.c: Fix security driver usage in hotplug/unplug

If there is a problem with VM startup, PCI devices may be left
assigned to pci-stub / pci-back. Adding a call to reattach
host devices in the cleanup path is required.

* qemu/qemu_driver.c: qemuDomainReAttachHostDevices() when
  VM startup fails

Remove all the QEMU driver calls for setting file ownership and
process uid/gid. Instead wire in the QEMU DAC security driver,
stacking it ontop of the primary SELinux/AppArmour driver.

* qemu/qemu_driver.c: Switch over to new DAC security driver

This new security driver is responsible for managing UID/GID changes
to the QEMU process, and any files/disks/devices assigned to it.

* qemu/qemu_conf.h: Add flag for disabling automatic file permission
  changes
* qemu/qemu_security_dac.h, qemu/qemu_security_dac.c: New DAC driver
  for QEMU guests
* Makefile.am: Add new files

* qemu/qemu_conf.h: Add securityPrimaryDriver and
  securitySecondaryDriver fields to 'struct qemud_driver'
* Makefile.am: Add new files
* qemu/qemu_security_stacked.c, qemu/qemu_security_stacked.h: A
  simple stacked security driver

Pulling the disk labelling code out of the exec hook, and into
libvirtd will allow it to access shared state in the daemon. It
will also make debugging & error reporting easier / more reliable.

* qemu/qemu_driver.c: Move initial disk labelling calls up into
  libvirtd. Add cleanup of disk labels upon failure

If a VM fails to start, we can't simply free the security label
strings, we must call the domainReleaseSecurityLabel() method
otherwise the reserved 'mcs' level will be leaked in SElinux

* src/qemu/qemu_driver.c: Invoke domainReleaseSecurityLabel()
  when domain fails to start

The current security driver architecture has the following
split of logic

 * domainGenSecurityLabel

    Allocate the unique label for the domain about to be started

 * domainGetSecurityLabel

    Retrieve the current live security label for a process

 * domainSetSecurityLabel

    Apply the previously allocated label to the current process
    Setup all disk image / device labelling

 * domainRestoreSecurityLabel

    Restore the original disk image / device labelling.
    Release the unique label for the domain

The 'domainSetSecurityLabel' method is special because it runs
in the context of the child process between the fork + exec.

This is require in order to set the process label. It is not
required in order to label disks/devices though. Having the
disk labelling code run in the child process limits what it
can do.

In particularly libvirtd would like to remember the current
disk image label, and only change shared image labels for the
first VM to start. This requires use & update of global state
in the libvirtd daemon, and thus cannot run in the child
process context.

The solution is to split domainSetSecurityLabel into two parts,
one applies process label, and the other handles disk image
labelling. At the same time domainRestoreSecurityLabel is
similarly split, just so that it matches the style. Thus the
previous 4 methods are replaced by the following 6 new methods

 * domainGenSecurityLabel

    Allocate the unique label for the domain about to be started
    No actual change here.

 * domainReleaseSecurityLabel

   Release the unique label for the domain

 * domainGetSecurityProcessLabel

   Retrieve the current live security label for a process
   Merely renamed for clarity.

 * domainSetSecurityProcessLabel

   Apply the previously allocated label to the current process

 * domainRestoreSecurityAllLabel

    Restore the original disk image / device labelling.

 * domainSetSecurityAllLabel

    Setup all disk image / device labelling

The SELinux and AppArmour drivers are then updated to comply with
this new spec. Notice that the AppArmour driver was actually a
little different. It was creating its profile for the disk image
and device labels in the 'domainGenSecurityLabel' method, where as
the SELinux driver did it in 'domainSetSecurityLabel'. With the
new method split, we can have consistency, with both drivers doing
that in the domainSetSecurityAllLabel method.

NB, the AppArmour changes here haven't been compiled so may not
build.

The QEMU driver is doing 90% of the calls to check for static vs
dynamic labelling. Except it is forgetting todo so in many places,
in particular hotplug is mistakenly assigning disk labels. Move
all this logic into the security drivers themselves, so the HV
drivers don't have to think about it.

* src/security/security_driver.h: Add virDomainObjPtr parameter
  to virSecurityDomainRestoreHostdevLabel and to
  virSecurityDomainRestoreSavedStateLabel
* src/security/security_selinux.c, src/security/security_apparmor.c:
  Add explicit checks for VIR_DOMAIN_SECLABEL_STATIC and skip all
  chcon() code in those cases
* src/qemu/qemu_driver.c: Remove all checks for VIR_DOMAIN_SECLABEL_STATIC
  or VIR_DOMAIN_SECLABEL_DYNAMIC. Add missing checks for possibly NULL
  driver entry points.

Allows the initiator to use a variety of IQNs rather than just the
system IQN when creating iSCSI pools.
* docs/schemas/storagepool.rng: extends the syntax with <iqn name="..."/>
* src/conf/storage_conf.[ch]: read and stores the iqn name
* src/storage/storage_backend_iscsi.[ch]: implement the IQN selection
  when detected