* libvirt.pc.in: Add missing '/api/' in path
* libvirt.spec.in, mingw32-libvirt.spec.in: s/apis/api/
(cherry picked from commit 5452e88c)

If we migrate to fd, spec->fwdType is not MIGRATION_FWD_DIRECT,
we will close spec->dest.fd.local in qemuMigrationRun(). So we
should set spec->dest.fd.local to -1 in qemuMigrationRun().

Bug present since 0.9.5 (commit 32617617).
(cherry picked from commit b19c236d)

We should not set *outfd or *errfd if virExecWithHook() failed
because the caller may close these fds.

Bug present since v0.4.5 (commit 60ed1d2a).
(cherry picked from commit 746ff701)

Wen Congyang reported that we have a double-close bug if we fail
virFDStreamOpenInternal, since childfd duplicated one of the fds[]
array contents.  In truth, since we always transfer both members
of fds to other variables, we should close the fds through those
other names, and just use fds[] for pipe().

Bug present since 0.9.0 (commit e886237a).

* src/fdstream.c (virFDStreamOpenFileInternal): Swap scope of
childfd and fds[], to avoid a double close.
(cherry picked from commit f3cfc7c8)

KAMEZAWA Hiroyuki reported a nasty double-free bug when virCommand
is used to convert a string into input to a child command.  The
problem is that the poll() loop of virCommandProcessIO would close()
the write end of the pipe in order to let the child see EOF, then
the caller virCommandRun() would also close the same fd number, with
the second close possibly nuking an fd opened by some other thread
in the meantime.  This in turn can have all sorts of bad effects.

The bug has been present since the introduction of virCommand in
commit f16ad06f.

This is based on his first attempt at a patch, at
https://bugzilla.redhat.com/show_bug.cgi?id=823716

* src/util/command.c (_virCommand): Drop inpipe member.
(virCommandProcessIO): Add argument, to avoid closing caller's fd
without informing caller.
(virCommandRun, virCommandNewArgs): Adjust clients.
(cherry picked from commit da831afc)

Conflicts:

	src/util/command.c

virCommandRunAsync() will set errfd if it succeed. We should
close it if virFDStreamOpenInternal() fails.
(cherry picked from commit 655cffa0)

If the system does not support bypass cache, we will close fd,
but it is uninitialized.
(cherry picked from commit 0a045f01)

The uhci1, uhci2, uhci3 companion controllers for ehci1 must
have a master start port set. Since this value is predictable
we should set it automatically if the app does not supply it
(cherry picked from commit 03b804a2)

Currently each USB2 companion controller gets put on a separate
PCI slot. Not only is this wasteful of PCI slots, but it is not
in compliance with the spec for USB2 controllers. The master
echi1 and all companion controllers should be in the same slot,
with echi1 in function 7, and uhci1-3 in functions 0-2 respectively.

* src/qemu/qemu_command.c: Special case handling of USB2 controllers
  to apply correct pci slot assignment
* tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.args,
  tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.xml: Expand
  test to cover automatic slot assignment
(cherry picked from commit 1ebd52cb)

Conflicts:

	tests/qemuxml2xmltest.c

The virDomainDeviceInfoIsSet API was only checking if an
address or alias was set in the struct. Thus if only a
rom bar setting / filename, boot index, or USB master
value was set, they could be accidentally dropped when
formatting XML
(cherry picked from commit 2c195fdb)

Conflicts:

	src/conf/domain_conf.c

(crobinso: some elements aren't in maint branch, drop them)

The glibc ones (intentionally) cannot handle ptys opened in a
devpts not mounted at /dev/pts.

Drop the (un-exported, unused) virFileOpenTtyAt.
Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 80710c69)

Conflicts:

	src/lxc/lxc_controller.c

When using the xm/xend stack to manage instances there is a bug
that causes the emulated interfaces to be unusable when the vif
config contains type=ioemu.

The current code already has a special quirk to not use this
keyword if no specific model is given for the emulated NIC
(defaulting to rtl8139).
Essentially it works because regardless of the type argument,i
the Xen stack always creates emulated and paravirt interfaces and
lets the guest decide which one to use. So neither xl nor xm stack
actually require the type keyword for emulated NICs.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 10c31135)

On newer xend (v3.x and after) there is no state and domid reported
for inactive domains. When initially creating connections this is
handled in various places by assigning domain->id = -1.
But once an instance has been running, the id is set to the current
domain id. And it does not change when the instance is shut down.
So when querying the domain info, the hypervisor driver, which gets
asked first will indicate it cannot find information, then the
xend driver is asked and will set the status to NOSTATE because it
checks for the -1 domain id.
Checking domain/status for 0 seems to be more reliable for that.

One note: I am not sure whether the domain->id also should get set
back to -1 whenever any sub-driver thinks the instance is no longer
running.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=746007
BugLink: http://bugs.launchpad.net/bugs/929626Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 26e9ef47)

(crobinso: Add Stefan to AUTHORS. maint only)

filename is not initialized to NULL while it's unconditionally freed in
the error path.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit 360afebf)

On CentOS5 with xen-3.0.3:

 Program received signal SIGSEGV, Segmentation fault.
 virFree (ptrptr=0x8) at util/memory.c:310
 310         free(*(void**)ptrptr);
 (gdb) bt
 #0  virFree (ptrptr=0x8) at util/memory.c:310
 #1  0x00002aaaaae167c8 in xenXMDomainDefineXML (conn=0x694e80, xml=0x6b2ce0 "P\fk") at xen/xm_internal.c:1199
 #2  0x00002aaaaae070d7 in xenUnifiedDomainDefineXML (conn=0x8,
     xml=0x6ac040 "<domain type='xen'>\n  <name>pv</name>\n  <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n  <memory>1048576</memory>\n  <currentMemory>1048576</currentMemory>\n  <vcpu>1</vcpu>\n  <os>\n    <type arch='x8"...) at xen/xen_driver.c:1524
 #3  0x00002aaaaada7803 in virDomainDefineXML (conn=0x694e80,
     xml=0x6ac040 "<domain type='xen'>\n  <name>pv</name>\n  <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n  <memory>1048576</memory>\n  <currentMemory>1048576</currentMemory>\n  <vcpu>1</vcpu>\n  <os>\n    <type arch='x8"...) at libvirt.c:7823
 #4  0x0000000000426173 in cmdEdit (ctl=0x7fffffffb8e0, cmd=<value optimized out>) at virsh.c:14882
 #5  0x000000000041c9ce in vshCommandRun (ctl=0x7fffffffb8e0, cmd=0x658c50) at virsh.c:17712
 #6  0x000000000042c3b9 in main (argc=1, argv=<value optimized out>) at virsh.c:19317
Signed-off-by: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit 046b0a69)

It just doesn't really make sense and confuses virt-manager
(cherry picked from commit efb0839c)

Conflicts:

	src/xenxs/xen_sxpr.c

On xen 4.1 I observed configurations that look like:

(image
    (hvm
        (kernel '')
        (loader '/foo/bar')
))

The kernel element is there but unset. This leads to an empty <kernel/>
element in the XML and even worse makes us skip the boot order parsing
and therefore not emit a <boot device='$dev>'/> element which breaks CD
booting.
(cherry picked from commit dca1a6b4)

otherwise a missing UUID in a domain config just shows:

error: An error occurred, but the cause is unknown

Now we have:

error: configuration file syntax error: config value uuid was missing
(cherry picked from commit c5d2984c)

(cherry picked from commit 6dd8532d)

The stream lock is unlocked twice instead of being locked and then
unlocked. Probably a typo.
(cherry picked from commit 107f51b6)

Conflicts:

	AUTHORS

This patch adds another callback to a FDstream object. The original
callback is used by the daemon stream driver to handle events.

This callback is called if and only if the stream is about to be closed.
This might be used to handle cleanup steps after a fdstream exits. This
will be used later on in ensuring mutually exclusive access to consoles.

* src/fdstream.c:
        - emit the callback, when stream is being closed
        - add data structures needed to handle the callback
        - add function to register callback
* src/fdstream.h:
        - define function prototypes for the callback
(cherry picked from commit 0c4bfdda)

This patch causes the fdstream driver to call the stream event callback
if virStreamAbort() is called on a stream using this driver.

A remote handler for a stream can only detect changes via stream events,
so this event callback is necessary in order to enable a daemon to abort
a stream in such a way that the client will see the change.

* src/fdstream.c:
        - modify close function to call stream event callback
(cherry picked from commit 95fdc1bc)

Due to the asynchronous nature of streams, we might continue to
receive some stream packets from the server even after we have
shutdown the stream on the client side. These should be discarded
silently, rather than raising an error in the RPC layer.

* src/rpc/virnetclient.c: Discard stream data silently
(cherry picked from commit a38710bd)

Very occasionally the sequence of events from poll would result
in getting a HANGUP on its own, instead of a HANGUP+READABLE
at the same time. In the former case we would send back an error
event to the client, but never send the empty packet to indicate
EOF.
(cherry picked from commit 1d46b2e9)

If we receive an error on the stream, set the EOF marker so
that any further (bogus) incoming data is dropped.

* src/rpc/virnetclientstream.c: Set EOF on stream
(cherry picked from commit bc61aa12)

Do not crash if virStreamFinish is called after error.

==11000== Invalid read of size 4
==11000==    at 0x373A8099A0: pthread_mutex_lock (pthread_mutex_lock.c:51)
==11000==    by 0x4C7CADE: virMutexLock (threads-pthread.c:85)
==11000==    by 0x4D57C31: virNetClientStreamRaiseError (virnetclientstream.c:203)
==11000==    by 0x4D385E4: remoteStreamFinish (remote_driver.c:3541)
==11000==    by 0x4D182F9: virStreamFinish (libvirt.c:14157)
==11000==    by 0x40FDC4: cmdScreenshot (virsh.c:3075)
==11000==    by 0x42BA40: vshCommandRun (virsh.c:14922)
==11000==    by 0x42ECCA: main (virsh.c:16381)
==11000==  Address 0x59b86c0 is 16 bytes inside a block of size 216 free'd
==11000==    at 0x4A06928: free (vg_replace_malloc.c:427)
==11000==    by 0x4C69E2B: virFree (memory.c:310)
==11000==    by 0x4D57B56: virNetClientStreamFree (virnetclientstream.c:184)
==11000==    by 0x4D3DB7A: remoteDomainScreenshot (remote_client_bodies.h:1812)
==11000==    by 0x4CFD245: virDomainScreenshot (libvirt.c:2903)
==11000==    by 0x40FB73: cmdScreenshot (virsh.c:3029)
==11000==    by 0x42BA40: vshCommandRun (virsh.c:14922)
==11000==    by 0x42ECCA: main (virsh.c:16381)
(cherry picked from commit be5ec766)

commit 984840a2 removed the
notification of waiting calls when VIR_NET_CONTINUE messages
arrive. This was to fix the case of a virStreamAbort() call
being prematurely notified of completion.

The problem is that sometimes there are dummy calls from a
virStreamRecv() call waiting that *do* need to be notified.

These dummy calls should have a status VIR_NET_CONTINUE. So
re-add the notification upon VIR_NET_CONTINUE, but only if
the waiter also has a status of VIR_NET_CONTINUE.

* src/rpc/virnetclient.c: Notify waiting call if stream data
  arrives
* src/rpc/virnetclientstream.c:  Mark dummy stream read packet
  with status VIR_NET_CONTINUE
(cherry picked from commit cb610092)

Ever since commit c964b6aa, make was trying to find the timestamp
of '""./apibuild.py".stamp"', but only touching 'apibuild.py.stamp',
and thus always rebuilding.  Reported by Daniel P. Berrange.

* docs/Makefile.am (APIBUILD, APIBUILD_STAMP): Omit bogus quotes.
(cherry picked from commit c0057d9a)

Language bindings may well want to use the libvirt-api.xml and
libvirt-qemu-api.xml files to either auto-generate themselves,
or sanity check the manually written bindings for completeness.
Currently these XML files are not installed as standard, merely
ending up as a %doc file in the RPM.

This changes them to be installed into $prefix/share/libvirt/apis/
The *-refs.xml files are not installed, since those are only
useful during generation of the online API doc files.

The pkg-config file is enhanced so that you can query the install
location of the API files. eg

  # pkg-config --variable=libvirt_qemu_api libvirt
  /home/berrange/builder/i686-pc-mingw32/sys-root/mingw/share/libvirt/libvirt-qemu-api.xml

* docs/Makefile.am: Install libvirt-api.xml & libvirt-qemu-api.xml
* libvirt.pc.in: Add vars for querying API install location
* libvirt.spec.in, mingw32-libvirt.spec.in: Include API XML files
(cherry picked from commit c95c90ee)

On rawhide, gcc is new enough to output new DWARF information that
pdwtags has not yet learned, but the resulting 'make check' output
was rather confusing:

$ make -C src check
...
  GEN    virkeepaliveprotocol-structs
die__process_function: DW_TAG_INVALID (0x4109) @ <0x58c> not handled!
WARNING: your pdwtags program is too old
WARNING: skipping the virkeepaliveprotocol-structs test
WARNING: install dwarves-1.3 or newer
...
$ pdwtags --version
v1.9

I've filed the pdwtags deficiency as
https://bugzilla.redhat.com/show_bug.cgi?id=772358

* src/Makefile.am (PDWTAGS): Don't leave -t file behind on version
mismatch.  Soften warning message, since 1.9 is newer than 1.3.
Don't leak stderr from broken version.
(cherry picked from commit cf6d3625)

  CC     libvirt_driver_xenapi_la-xenapi_driver.lo
xenapi/xenapi_driver.c: In function 'xenapiDomainGetVcpus':
xenapi/xenapi_driver.c:1209:21: error: variable 'cpus' set but not used [-Werror=unused-but-set-variable]

* src/xenapi/xenapi_driver.c (xenapiDomainGetVcpus): Silence
compiler warning.
(cherry picked from commit 787b0a22)

I got these distcheck failures with sanlock enabled:

ERROR: files left in build directory after distclean:
./tools/virt-sanlock-cleanup
./src/locking/qemu-sanlock.conf

* src/Makefile.am (DISTCLEANFILES) [HAVE_SANLOCK]: Clean built
file.
* tools/Makefile.am (DISTCLEANFILES): Likewise.
(cherry picked from commit c654ba88)
plus tweak to DISTCLEANFILES from commit ddf3bd32, although that
full commit is too invasive to backport

I am getting this failure with 'make distcheck':

  GEN    ../../src/remote_protocol-structs
/bin/sh: ../../src/remote_protocol-structs-t: Permission denied
make[4]: *** [../../src/remote_protocol-structs] Error 1

since it attempts a sub-run of a VPATH 'make check' where $(srcdir)
is intentionally read-only.  I'm not sure which commit introduced
the problem, although I suspect it was around 62dee6fa when I
refactored protocol struct checking to be more powerful.

$(@F) is required by POSIX, and although it is not yet portable
to all make implementations, we already require GNU make.

* src/Makefile.am (PDWTAGS): Generate temp file into current
directory, since $(srcdir) is read-only during distcheck.
(cherry picked from commit 2d45ae5a)

We were using the libvirt release version (like 0.9.11) and not
the configure version (which for stable releases is 0.9.11.X)

Most other places got this right so hopefully that's all the fallout
from the version format change :)
Signed-off-by: NCole Robinson <crobinso@redhat.com>
(cherry picked from commit 002b18b3)

Use a witness file approach like we do for python/generator.py,
as suggested by Eric. Fixes the build issue reported here:

https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com>
(cherry picked from commit c964b6aa)

Conflicts:

	.gitignore - context with other commits not backported

Since for stable releases, some test files were over the 99 char
limit for traditional tar filenames.

Suggested by Osier here:
https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com>
(cherry picked from commit ddd6bef4)

Every now & then, with parallel builds, we get a failure to
validate hvsupport.html.in.  I eventually noticed that this
is because we get 2 instances of the generator running at
once.

We already list hvsupport.html.in in BUILT_SOURCES but this
was not working. It turns out the flaw is that we were
adding deps to the 'all:' target instead of the 'all-am:'
target. BUILT_SOURCES is a dep of 'all', so any custom
targets written in Makefile.am must use 'all-am:' so that
they don't get run until BUILT_SOURCES are completely
generated

* docs/Makefile.am: s/all/all-am/
(cherry picked from commit 4f4b496e)
(cherry picked from commit 26fdec39)

I hit a VERY weird testsuite failure on rawhide, which included
_binary_ output to stderr, followed by a hang waiting for me
to type something! (Here, using ^@ for NUL):

$ ./commandtest
TEST: commandtest
      WARNING: gnome-keyring:: couldn't send data: Bad file descriptor
.WARNING: gnome-keyring:: couldn't send data: Bad file descriptor
.WARNING: gnome-keyring:: couldn't send data: Bad file descriptor
WARNING: gnome-keyring:: couldn't send data: Bad file descriptor
.8^@^@^@8^@^@^@^A^@^@^@^Bay^A^@^@^@)PRIVATE-GNOME-KEYRING-PKCS11-PROTOCOL-V-1

I finally traced it to the fact that gnome-keyring, called via
gnutls_global_init which is turn called by virNetTLSInit, opens
an internal fd that it expects to communicate to via a
pthread_atfork handler (never mind that it violates POSIX by
using non-async-signal-safe functions in that handler:
https://bugzilla.redhat.com/show_bug.cgi?id=772320).

Our problem stems from the fact that we pulled the rug out from
under the library's expectations by closing an fd that it had
just opened.  While we aren't responsible for fixing the bugs
in that pthread_atfork handler, we can at least avoid the bugs
by not closing the fd in the first place.

* tests/commandtest.c (mymain): Avoid closing fds that were opened
by virInitialize.
(cherry picked from commit 74ff5750)

On F16 at least, empty volume groups don't have a directory under /dev.
The directory only appears once a logical volume is created.

This tickles some behavior in BackendStablePath which ends with
libvirt sleeping for 5 seconds while waiting for the directory to appear.
This causes all sorts of problems for the virStorageVolLookupByPath API
which virtinst uses, even if trying to resolve a path that is independent
of the logical pool.

In reality we don't even need to do that checking since logical pools
always have a stable target path. Short circuit the polling in that
case.

Fixes bug 782261
(cherry picked from commit 275155f6)

The init script for the daemon requests to start HAL although it has
been deprecated long time ago. This patch removes the dependency.
(cherry picked from commit 2dcca3ec)