Commit 7bff56a0 worked in an incremental build, but fails for a
fresh clone; apparently, if make sees both an actual file
spelling and an inference rule, only the exact spelling is used.

  CCLD   libvirt_driver_test.la
  CC     libvirt_driver_remote_la-remote_driver.lo
remote/remote_driver.c:4707:34: fatal error: remote_client_bodies.h: No such file or directory
compilation terminated.

BUILT_SOURCES to the rescue, instead of trying to mess with .lo
dependencies directly.

* src/Makefile.am (REMOTE_DRIVER_PREREQS, %remote_driver.lo): Drop...
(BUILT_SOURCES): ...and add here instead.
(cherry picked from commit ca02b101)

Conflicts:

	src/Makefile.am

We had a distributed file (remote_protocol.h, which in turn was
a prereq to remote_driver.c) depending on a generated file
(libvirt_probes.h), which is a no-no for a VPATH build from a
read-only source tree (no wonder 'make distcheck' tests precisely
that situation):

     File `libvirt_driver_remote.la' does not exist.
       File `libvirt_driver_remote_la-remote_driver.lo' does not exist.
             Prerequisite `libvirt_probes.h' is newer than target `../../src/remote/remote_protocol.h'.
            Must remake target `../../src/remote/remote_protocol.h'.
Invoking recipe from Makefile:7464 to update target `../../src/remote/remote_protocol.h'.
make[3]: Entering directory `/home/remote/eblake/libvirt-tmp2/build/libvirt-0.9.12/_build/src'
  GEN    ../../src/remote/remote_protocol.h
cannot create ../../src/remote/remote_protocol.h: Permission denied at ../../src/rpc/genprotocol.pl line 31.
make[3]: *** [../../src/remote/remote_protocol.h] Error 13

Rather than making distributed .c files depend on generated files, we
really want to ensure that compilation into .lo files is not attempted
until the generated files are present, done by this patch.  Since there
were two different sets of conditionally generated files that both
feed the .lo file, I had to introduce a new variable REMOTE_DRIVER_PREREQS
to keep automake happy.

After that fix, the next issue was that make treats './foo' and 'foo'
differently in determining whether an implicit %foo rule is applicable,
with the result that locking/qemu-sanlock.conf wasn't properly being
built at the right times.  Also, the output for using the .aug test
files was a bit verbose.

After fixing the src directory, the next error is related to the docs
directory, where the tarball is missing a stamp file and thus tries to
regenerate files that are already present:

  GEN    ../../docs/apibuild.py.stamp
Traceback (most recent call last):
  File "../../docs/apibuild.py", line 2511, in <module>
    rebuild("libvirt")
  File "../../docs/apibuild.py", line 2495, in rebuild
    builder.serialize()
  File "../../docs/apibuild.py", line 2424, in serialize
    output = open(filename, "w")
IOError: [Errno 13] Permission denied: '../../docs/libvirt-api.xml'
make[5]: *** [../../docs/apibuild.py.stamp] Error 1

and fixing that exposed another case of a distributed file (generated
html) depending on a built file (libvirt.h), but only when doing an
in-tree build, because of a file glob.

* src/Makefile.am ($(srcdir)/remote/remote_driver.c): Change...
(libvirt_driver_remote_la-remote_driver.lo): ...to the real
dependency.
($(builddir)/locking/%-sanlock.conf): Drop $(builddir), so that
rule gets run in time for test_libvirt_sanlock.aug.
(test_libvir*.aug): Cater to silent build.
(conf_DATA): Don't ship qemu-sanlock.conf in the tarball, since it
is trivial to regenerate.
* docs/Makefile.am (EXTRA_DIST): Ship our stamp file.
($(APIBUILD_STAMP)): Don't depend on generated file.
(cherry picked from commit 7bff56a0)

Conflicts:

	src/Makefile.am

'make dist' was depending on *protocol-structs files, which are
stored in git but in turn depended on generated files.  We still
want to ship the protocol-structs files, but by renaming the
tests to something not matching a file name, we separate 'make
check' (which depends on the generated file) from 'make dist'
(which only depends on the git files).  After all, the tarball
should never depend on a generated file not stored in git.

I found one more case of a git file depending on a generated
file, in a bogus virkeycode.c listing; but at least this one
had no associated rules so it never broke 'make dist'.

Reported by Wen Congyang.  Latent bug has been present since
commit 62dee6fa, but only recently exposed by commit 7bff56a0.

* src/Makefile.am ($(srcdir)/util/virkeycode.c): Drop useless
dependency.
(BUILT_SOURCES): ...and build virkeymaps.h sooner.
(PROTOCOL_STRUCTS): Rather than depend on the struct file...
(check-local): ...convert things into a phony target of...
(check-protocol): ...a new check.
($(srcdir)/remote_protocol-struct): Rename to isolate the distributed
file from the conditional test.
(PDWTAGS): Deal with rename.  Swap to compare 'expected actual'.
(cherry picked from commit 9b5970c6)

Tell the user what CPU mode value is wrong
(cherry picked from commit 92cbe7ae)

Libvirt updates the configuration of SPICE server only when something
changes. This is unfortunate when the user wants to disconnect a
existing spice session when the connected attribute is already
"disconnect".

This patch modifies the conditions for calling the password updater to
be called when nothing changes, but the connected attribute is already
"disconnect".
(cherry picked from commit e0f0131d)

While unescaping the commands the commands passed through to the monitor
function qemuMonitorUnescapeArg() initialized lenght of the input string
to strlen()+1 which is fine for alloc but not for iteration of the
string.

This patch fixes the off-by-one error and drops the pointless check for
a single trailing slash that is automaticaly handled by the default
branch of switch.
(cherry picked from commit 0f4660c8)

The attach-disk command used with parameter --cache created an invalid
XML snippet as the beginning of the <driver> element was not printed
when used solely with --cache and no other attribute to driver.
(cherry picked from commit 5b474026)

libvirt.spec.in: s/{?rhel}/%{?rhel}/
(cherry picked from commit 48939a4a)

Python exceptions are different than libvirt errors, and we had
some corner case bugs on OOM situations.

* python/libvirt-override.c (libvirt_virDomainSnapshotListNames)
(libvirt_virDomainSnapshotListChildrenNames): Use correct error
returns, avoid segv on OOM, and avoid memory leaks on error.
(cherry picked from commit a0de5d78)

* python/libvirt-override.c (libvirt_virDomainGetVcpus)
(libvirt_virDomainGetVcpuPinInfo): Use Py_XDECREF instead of
open-coding it.
(cherry picked from commit 8566618f)

Currently, if qemuProcessStart fail at some point, e.g. because
domain being started wants a PCI/USB device already assigned to
a different domain, we jump to cleanup label where qemuProcessStop
is performed. This unconditionally calls virSecurityManagerRestoreAllLabel
which is wrong because the other domain is still using those devices.

However, once we successfully label all devices/paths in
qemuProcessStart() from that point on, we have to perform a rollback
on failure - that is - we have to virSecurityManagerRestoreAllLabel.
(cherry picked from commit 86032b22)

Conflicts:

	src/qemu/qemu_process.c

Currently, we are passing only one boolean (migrated) so there is
no real profit in this. But it creates starting position for
next patch.
(cherry picked from commit 69dd7714)

Conflicts:

	src/qemu/qemu_process.c

A few examples for <interface> had a type='direct' interface with no
sub-elements. This is not allowed - a type='direct' interface must
have at least a source element. (Most likely the example was copied
from the type='user' or type='ethernet' examples - they *do* allow an
instance with no sub-elements).

There was also one place that mistakenly used %lt; ... %gt; instead of
&lt; ... &gt; (for some reason, I make that typo all the time).
(cherry picked from commit 549741ee)

Eric Blake and Guido Günther were guests during this week's
FLOSS Weekly podcast, giving insights into libvirt as a Free
Software project.  Also, there are several useful blogs on
virt-related topics.

* docs/relatedlinks.html.in (Blogs and Podcasts): New section.
(cherry picked from commit a0ac7450)

Ensure systemd is used in RHEL-7 and cgconfig is not used in
RHEL-7
(cherry picked from commit 1cdbe4d2)

Commits 51082301, 16d7b390, and 521cc447 introduced support for
'virsh snapshot-list --from' when talking to a server older than
0.9.5, but broke support for plain 'virsh snapshot-list' for the
same old server in the process.  Because the code is not properly
gated, we end up with a SIGSEGV during a strcmp with a NULL argument.

* tools/virsh.c (cmdSnapshotList): Don't waste time on fallbacks
when --from is not present.
(cherry picked from commit d9f60665)

Commit a80bb970 forgot to update authors.
(cherry picked from commit d41d2526)

we forgot to free fslist,just add VIR_FREE(fslist).
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
(cherry picked from commit e49d792f)

when do remount,the source and target should be the same
values specified in the initial mount() call.

So change fs->dst to src.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
(cherry picked from commit 0cb787bd)

otherwise migration fails for e.g. network filesystems like sheepdog
with:

   error: Invalid relative path 'virt-name': Invalid argument

while we should fail with:

    Migration may lead to data corruption if disks use cache != none

References:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676328
    https://www.redhat.com/archives/libvirt-users/2012-May/msg00088.html
(cherry picked from commit 3ac8fb54)

https://bugzilla.redhat.com/show_bug.cgi?id=801656
(cherry picked from commit 9ec6f818)

For pseries guest, spapr-vlan and spapr-vty is based
on spapr-vio address. According to model of network
device, the address type should be assigned automatically.
For serial device, serial pty device is recognized as
spapr-vty device, which is also on spapr-vio.

So this patch is to correct the address type of
spapr-vlan and spapr-vty, and build correct
command line of spapr-vty.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Reviewed-by:   Michael Ellerman<michaele@au1.ibm.com>
(cherry picked from commit 04a319ba)

While libvirt intentionally avoids -Wundef (after all, C99
guarantees sane semantics of treating undefined macros as 0),
the glibc insanity of #warning on _FORTIFY_SOURCE coupled with
what some people feel is the black magic of autoconf means
that other projects are likely to copy our snippet verbatim.
We can be nicer to other projects by making it easier to
integrate into projects that use -Wundef.

Suggested by Christophe Fergeau.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Be nice
to other projects using -Wundef.
(cherry picked from commit 1c2edf0f)

There is a theoretical problem of an extreme bug where we can get
into deadlock due to command handshaking.  Thanks to a pair of pipes,
we have a situation where the parent thinks the child reported an
error and is waiting for a message from the child to explain the
error; but at the same time the child thinks it reported success
and is waiting for the parent to acknowledge the success; so both
processes are now blocked.

Thankfully, I don't think this deadlock is possible without at
least one other bug in the code, but I did see exactly that sort
of situation prior to commit da831afc - I saw a backtrace where a
double close bug in the parent caused the parent to read from the
wrong fd and assume the child failed, even though the child really
sent success.

This potential deadlock is not quite like commit 858c2476 (a deadlock
due to multiple readers on one pipe preventing a write from completing),
although the solution is similar - always close unused pipe fds before
blocking, rather than after.

* src/util/command.c (virCommandHandshakeWait): Close unused fds
sooner.
(cherry picked from commit 5e8ab391)

They have now merged. Fedora details here:

https://lists.fedoraproject.org/pipermail/devel/2012-June/168227.html
(cherry picked from commit dd7bc51b)

Conflicts:

	libvirt.spec.in

(cherry picked from commit ee58b581)

Conflicts:

	tools/virsh.c

(cherry picked from commit 68fcfdb8)

Affected commands are: pool-start, vol-create-from.
(cherry picked from commit 05f8917f)

I came across a bug that the command line generated for passthrough
of the host parallel port /dev/parport0 by libvirt for QEMU is incorrect.

It currently produces:
-chardev tty,id=charparallel0,path=/dev/parport0
-device isa-parallel,chardev=charparallel0,id=parallel0

The first parameter is "tty". It sould be "parport".

If I launch qemu with -chardev parport,... it works as expected.

I have already filled a bug report (
https://bugzilla.redhat.com/show_bug.cgi?id=823879 ), the topic was
already on the list some months ago:

https://www.redhat.com/archives/libvirt-users/2011-September/msg00095.htmlSigned-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 7508338f)

Noticed during the previous commit.

* src/util/command.c: Fix some spacing and break long lines.
(cherry picked from commit a3bc393e)

It is possible to deadlock libvirt by having a domain with XML
longer than PIPE_BUF, and by writing a hook script that closes
stdin early.  This is because libvirt was keeping a copy of the
child's stdin read fd open, which means the write fd in the
parent will never see EPIPE (remember, libvirt should always be
run with SIGPIPE ignored, so we should never get a SIGPIPE signal).
Since there is no error, libvirt blocks waiting for a write to
complete, even though the only reader is also libvirt.  The
solution is to ensure that only the child can act as a reader
before the parent does any writes; and then dealing with the
fallout of dealing with EPIPE.

Thankfully, this is not a security hole - since the only way to
trigger the deadlock is to install a custom hook script, anyone
that already has privileges to install a hook script already has
privileges to do any number of other equally disruptive things
to libvirt; it would only be a security hole if an unprivileged
user could install a hook script to DoS a privileged user.

* src/util/command.c (virCommandRun): Close parent's copy of child
read fd earlier.
(virCommandProcessIO): Don't let EPIPE be fatal; the child may
be done parsing input.
* tests/commandhelper.c (main): Set up a SIGPIPE situation.
* tests/commandtest.c (test20): Trigger it.
* tests/commanddata/test20.log: New file.
(cherry picked from commit 858c2476)

glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:

In file included from /usr/include/limits.h:27:0,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:169,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:34,
                 from util/bitmap.c:26:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
cc1: all warnings being treated as errors

Work around this by only conditionally defining _FORTIFY_SOURCE,
in the case where glibc can actually use it.  The trick is using
AH_VERBATIM instead of AC_DEFINE.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Squelch
_FORTIFY_SOURCE when needed to avoid glibc #warnings.
(cherry picked from commit 2af63b1c)

Probably a result of copy&paste...
(cherry picked from commit 461ed421)

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 resolves:

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

The problem is that an interface with type='hostdev' will have an
alias of the form "hostdev%d", while the function that looks through
existing netdevs to determine the name to use for a new addition will
fail if there's an existing entry that does not match the form
"net%d".

This is another of the handful of places that need an exception due to
the hybrid nature of <interface type='hostdev'> (which is not exactly
an <interface> or a <hostdev>, but is both at the same time).
(cherry picked from commit 6734ce7b)

This patch makes virt-pki-validate work with certificates that have
acl or xattr set. Otherwise it failing due to wrong permissions.
(cherry picked from commit d4fb6694)

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)