I am not a fan of fixed-width buffers.  All it takes is a
linear chain of more than 100 snapshots to mess up 'virsh
snapshot-list --tree'.  Now that virBuffer is more powerful,
we might as well exploit its power.

* tools/virsh.c (cmdNodeListDevicesPrint): Simplify to use a
virBuffer instead of fixed-width prefix, factor guts, and rename...
(vshTreePrint, vshTreePrintInternal): ...along with new helper.
(cmdNodeListDevices, cmdSnapshotList): Update callers.

Right now, the only way to get at the contents of a virBuffer is
to destroy it.  But there are cases in my upcoming patches where
peeking at the contents makes life easier.  I suppose this does
open up the potential for bad code to dereference a stale pointer,
by disregarding the docs that the return value is invalid on the
next virBuf operation, but such is life.

* src/util/buf.h (virBufferCurrentContent): New declaration.
* src/util/buf.c (virBufferCurrentContent): Implement it.
* src/libvirt_private.syms (buf.h): Export it.
* tests/virbuftest.c (testBufAutoIndent): Test it.

My latest patch for RPC rework (a2c304f6) introduced a memory leak.
virNetMessageEncodeHeader() is calling VIR_ALLOC_N(msg->buffer, ...)
despite fact, that msg->buffer isn't VIR_FREE()'d on all paths calling
the function. Therefore, rather than injecting free statement switch to
VIR_REALLOC_N().

Previous commit

  commit 32a9aac2
  Author: William Jon McCann <william.jon.mccann@gmail.com>
  Date:   Thu May 3 12:36:27 2012 -0400

    Use XDG Base Directories instead of storing in home directory

Accidentally changed the umask when creating /var/run/libvirt
to 077. This prevents /var/run/libvirt being readable by non-root,
which is required for non-root to connect to libvirtd. Fix the
code so that umask 077 is only used for the non-privileged libvirtd
instance.

Only the non-privileged libvirtd instance uses $HOME. So avoid
running the code for migrating to XDG directories unless using
a non-privileged libvirtd

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.

Commit a80bb970 forgot to update authors.

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

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>

There is no code use the variable "src" in lxcContainerMountBasicFS.
so delete it and VIR_FREE.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

This fixes the build on 32bit systems which otherwise fails with:

virnetmessagetest.c: In function 'testMessageHeaderEncode':
virnetmessagetest.c:75:9: error: format '%zu' expects argument of type 'size_t', but argument 7 has type 'long unsigned int' [-Werror=format]

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

virDomainSnapshotPtr has a refcount member, but no one was able
to use it.  Furthermore, all of our other vir*Ptr objects have
a *Ref method to match their *Free method.  Thankfully, this is
client-side only, so we can use this new function regardless of
how old the server side is!  (I have future patches to virsh
that want to use it.)

* include/libvirt/libvirt.h.in (virDomainSnapshotRef): Declare.
* src/libvirt.c (virDomainSnapshotRef): Implement it.
* src/libvirt_public.syms (LIBVIRT_0.9.13): Export it.

When libvirtd forks off a new child, the child then calls virLogReset(),
which ends up closing file descriptors used as log outputs. However, we
recently started logging closed file descriptors, which means we need to
lock logging mutex which was already locked by virLogReset(). We don't
really want to log anything when we are in the process of closing log
outputs.

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

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>

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.

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.

When libvirtd is started and there is an unusable/not-connectable
leftover from earlier started machine, it's more reasonable to say
that the machine "crashed" if we know it was started with
"-no-shutdown".
This patch fixes that and also changes the other result (when machine
was started without "-no-shutdown") to "unknown", because the previous
"failed" reason means (according to include/libvirt/libvirt.h.in:174),
that the machine failed to start.

If you compile without NLS support, where _() is a no-op macro,
then we end up passing a string literal to a char*, provoking:

In file included from virsh.c:3639:0:
virsh-edit.c: In function ‘cmdSaveImageEdit’:
virsh-edit.c:97:13: error: assignment discards ‘const’ qualifier from pointer target type [-Werror]
virsh-edit.c:106:13: error: assignment discards ‘const’ qualifier from pointer target type [-Werror]

* tools/virsh-edit.c: Be const-safe.

They have now merged. Fedora details here:

https://lists.fedoraproject.org/pipermail/devel/2012-June/168227.html

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.

Commit 1c275e9a accidentally dropped the storage driver from
libvirtd, because it depended on a C preprocessor macro that
was not defined.  Furthermore, if you do './configure
--without-storage-dir --with-storage-disk' or any other combination
where you explicitly build a subset of storage backends excluding
the dir backend, then the build is broken.

Based on analysis by Osier Yang.

* configure.ac (WITH_STORAGE): Define top-level conditional.
* src/Makefile.am (mod_LTLIBRARIES): Build driver even when
storage_dir is disabled.
* daemon/libvirtd.c: Pick up storage driver for any backend, not
just dir.
* daemon/Makefile.am (libvirtd_LDADD): Likewise.

Since we are allocating RPC buffer dynamically, we can increase limits
for max. size of RPC message and RPC string. This is needed to cover
some corner cases where libvirt is run on such huge machines that their
capabilities XML is 4 times bigger than our current limit. This leaves
users with inability to even connect.

Currently, we are allocating buffer for RPC messages statically.
This is not such pain when RPC limits are small. However, if we want
ever to increase those limits, we need to allocate buffer dynamically,
based on RPC message len (= the first 4 bytes). Therefore we will
decrease our mem usage in most cases and still be flexible enough in
corner cases.

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.

QEMU 1.1.0 has been officially released. With 1.1.0 QEMU went back to
three-digits version even for the initial release and I renamed the data
files to match this fact. They were generated with

qemu-system-x86_64 -help >tests/qemuhelpdata/qemu-1.1.0
qemu-system-x86_64 \
    -device ? \
    -device pci-assign,? \
    -device virtio-blk-pci,? \
    -device virtio-net-pci,? \
    -device scsi-disk,? 2>tests/qemuhelpdata/qemu-1.1.0-device

Affected commands are: pool-start, vol-create-from.

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>

Noticed during the previous commit.

* src/util/command.c: Fix some spacing and break long lines.

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.

Although src/util/viratomic.h has been added to the repo, up until now
it hasn't been used. Stefan Berger is using it in his proposed dhcp
snooping patches, and an rpm build with those patches failed due to
viratomic.h not being packed up with the rest of the sources.

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.

I noticed this during 'make syntax-check':

prohibit_readlink
grep: Unmatched ( or \(

* cfg.mk (exclude_file_name_regexp--sc_prohibit_readlink): Fix
mismatched '('.

EBADF errors are logged as warnings as they normally indicate a double
close bug. This patch also provides VIR_MASS_CLOSE helper to be user in
the only case of mass close after fork when EBADF should rather be
ignored.

Probably a result of copy&paste...

The stream lock is unlocked twice instead of being locked and then
unlocked. Probably a typo.