So far, we were dropping non-blocking calls whenever sending them would
block. In case a client is sending lots of stream calls (which are not
supposed to generate any reply), the assumption that having other calls
in a queue is sufficient to get a reply from the server doesn't work. I
tried to fix this in b1e374a7 but
failed and reverted that commit.

With this patch, non-blocking calls are never dropped (unless the
connection is being closed) and will always be sent.

Normally, when every call has a thread associated with it, the thread
may get the buck and be in charge of sending all calls until its own
call is done. When we introduced non-blocking calls, we had to add
special handling of new non-blocking calls. This patch uses event loop
to send data if there is no thread to get the buck so that any
non-blocking calls left in the queue are properly sent without having to
handle them specially. It also avoids adding even more cruft to client
IO loop in the following patches.

With this change in, non-blocking calls may see unpredictable delays in
delivery when the client has no event loop registered. However, the only
non-blocking calls we have are keepalives and we already require event
loop for them, which makes this a non-issue until someone introduces new
non-blocking calls.

When analyzing our debug log, I'm always confused about what each of the
pointers mean. Let's be explicit.

'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'.

Otherwise, 'make dist' gives multiple warnings like:

libvirt.pot:20814: warning: internationalized messages should not contain the `\r' escape sequence

* tools/virsh.c (vshAskReedit): Avoid \r in _().

so we can update file system quota

with persist=false the domain config file will not be updated.

for containers matching virDomainDiskIndexByName.

libvirt.spec.in: s/{?rhel}/%{?rhel}/

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.

* python/libvirt-override.c (libvirt_virDomainGetVcpus)
(libvirt_virDomainGetVcpuPinInfo): Use Py_XDECREF instead of
open-coding it.

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.

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

The two APIs are rather trivial; based on bits and pieces of other
existing APIs.  It leaves the door open for future extension to
qemu to report snapshots without metadata based on reading qcow2
internal snapshot names.

* src/qemu/qemu_driver.c (qemuDomainSnapshotIsCurrent)
(qemuDomainSnapshotHasMetadata): New functions.

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).

Pretty straightforward.

* src/remote/remote_protocol.x
(remote_domain_snapshot_is_current_args)
(remote_domain_snapshot_is_current_ret)
(remote_domain_snapshot_has_metadata_args)
(remote_domain_snapshot_has_metadata_ret): New structs.
(REMOTE_PROC_DOMAIN_SNAPSHOT_IS_CURRENT)
(REMOTE_PROC_DOMAIN_SNAPSHOT_HAS_METADATA): New RPC calls.
* src/remote/remote_driver.c (remote_driver): Call them.
* src/remote_protocol-structs: Regenerate.

Expose the recent API additions in virsh.  Borrows ideas from 'dominfo'
for the general type of information to display.

Output looks like:

$ tools/virsh snapshot-info fedora-local tmp
Name:           tmp
Domain:         fedora-local
Current:        no
State:          disk-snapshot
Parent:         -
Children:       1
Descendants:    2
Metadata:       yes

possibly with fewer lines when talking to older servers.

* tools/virsh.c (cmdSnapshotInfo): New command.
* tools/virsh.pod (snapshot-info): Document it.

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.

Ensure systemd is used in RHEL-7 and cgconfig is not used in
RHEL-7

Right now, starting from just a virDomainSnapshotPtr, and wanting to
know if it is the current snapshot for its respective domain, you have
to use virDomainSnapshotGetDomain(), then virDomainSnapshotCurrent(),
then compare the two names returned by virDomainSnapshotGetName().
It is a bit easier if we can directly query this information from the
snapshot itself.

Right now, it is possible to filter a snapshot listing based on
whether snapshots have metadata that would prevent domain deletion,
but the only way to learn if an individual snapshot has metadata is
to see if that snapshot appears in the list returned by a listing.
Additionally, I hope to expand the qemu driver in a future patch to
use qemu-img to reconstruct snapshot XML corresponding to internal
qcow2 snapshot names not otherwise tracked by libvirt (in part, so
that libvirt can guarantee that new snapshots are not created with
a name that would silently corrupt the existing portion of the qcow2
file); if I ever get that in, then it would no longer be an all-or-none
decision on whether snapshots have metadata, and becomes all the more
important to be able to directly determine that information from a
particular snapshot.

Other query functions (such as virDomainIsActive) do not have a flags
argument, but since virDomainHasCurrentSnapshot takes a flags argument,
I figured it was safer to provide a flags argument here as well.

* include/libvirt/libvirt.h.in (virDomainSnapshotIsCurrent)
(virDomainSnapshotHasMetadata): New declarations.
* src/libvirt.c (virDomainSnapshotIsCurrent)
(virDomainSnapshotHasMetadata): New functions.
* src/libvirt_public.syms (LIBVIRT_0.9.13): Export them.
* src/driver.h (virDrvDomainSnapshotIsCurrent)
(virDrvDomainSnapshotHasMetadata): New driver callbacks.

No semantic change; this will make it easier to refactor code.

* tools/virsh.c (cmdSnapshotList): Drop level of indentation, and
rename a variable.

Requiring the user to pass in parallel arrays of names and parents
is annoying; it means that you can't qsort one of the arrays without
invalidating the ordering of the other.  By refactoring this function
to use callbacks, we isolate the layout to be independent of the
printing, and a future patch can exploit that to improve layout.

* tools/virsh.c (vshTreePrintInternal): Use callbacks rather than
requiring a char** array.
(vshTreeArrayLookup): New helper function.
(vshTreePrint, cmdNodeListDevices, cmdSnapshotList): Update callers.

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.