Currently, if there's no hard memory limit defined for a domain,
libvirt tries to calculate one, based on domain definition and magic
equation and set it upon the domain startup. The rationale behind was,
if there's a memory leak or exploit in qemu, we should prevent the
host system trashing. However, the equation was too tightening, as it
didn't reflect what the kernel counts into the memory used by a
process. Since many hosts do have a swap, nobody hasn't noticed
anything, because if hard memory limit is reached, process can
continue allocating memory on a swap. However, if there is no swap on
the host, the process gets killed by OOM killer. In our case, the qemu
process it is.

To prevent this, we need to relax the hard RSS limit. Moreover, we
should reflect more precisely the kernel way of accounting the memory
for process. That is, even the kernel caches are counted within the
memory used by a process (within cgroups at least). Hence the magic
equation has to be changed:

  limit = 1.5 * (domain memory + total video memory) + (32MB for cache
          per each disk) + 200MB
(cherry picked from commit 3c83df67)

This is an adjustment to the fix for

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

to account for two bonehead mistakes I made.

commit ac2797cf attempted to fix a
problem with netlink in newer kernels requiring an extra attribute
with a filter flag set in order to receive an IFLA_VFINFO_LIST from
netlink. Unfortunately, the #ifdef that protected against compiling it
in on systems without the new flag went a bit too far, assuring that
the new code would *never* be compiled, and even if it had, the code
was incorrect.

The first problem was that, while some IFLA_* enum values are also
their existence at compile time, IFLA_EXT_MASK *isn't* #defined, so
checking to see if it's #defined is not a valid method of determining
whether or not to add the attribute. Fortunately, the flag that is
being set (RTEXT_FILTER_VF) *is* #defined, and it is never present if
IFLA_EXT_MASK isn't, so it's sufficient to just check for that flag.

And to top it off, due to the code not actually compiling when I
thought it did, I didn't realize that I'd been given the wrong arglist
to nla_put() - you can't just send a const value to nla_put, you have
to send it a pointer to memory containing what you want to add to the
message, along with the length of that memory.

This time I've actually sent the patch over to the other machine
that's experiencing the problem, applied it to the branch being used
(0.10.2) and verified that it works properly, i.e. it does fix the
problem it's supposed to fix. :-/
(cherry picked from commit 7c366506)

This patch fixes the lack of error messages when libvirt fails to find
VFINFO in a returned netlinke response message.

https://bugzilla.redhat.com/show_bug.cgi?id=827519#c10 is an example
of the error message that was previously logged when the
IFLA_VFINFO_LIST object was missing from the netlink response. The
reason for this failure is detailed in

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

Even though that root problem has been fixed, the experience of
finding the root cause shows us how important it is to properly log an
error message in these cases. This patch *seems* to replace the entire
function, but really most of the changes are due to moving code that
was previously inside an if() statement out to the top level of the
function (the original if() was reversed and made to log an error and
return).
(cherry picked from commit 846770e5)

This patch resolves:

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

When assigning an SRIOV virtual function to a guest using "intelligent
PCI passthrough" (<interface type='hostdev'>, which sets the MAC
address and vlan tag of the VF before passing its info to qemu),
libvirt first learns the current MAC address and vlan tag by sending
an NLM_F_REQUEST message for the VF's PF (physical function) to the
kernel via a NETLINK_ROUTE socket (see virNetDevLinkDump()); the
response message's IFLA_VFINFO_LIST section is examined to extract the
info for the particular VF being assigned.

This worked fine with kernels up until kernel commit
115c9b81928360d769a76c632bae62d15206a94a (first appearing in upstream
kernel 3.3) which changed the ABI to not return IFLA_VFINFO_LIST in
the response until a newly introduced IFLA_EXT_MASK field was included
in the request, with the (newly introduced, of course) RTEXT_FILTER_VF
flag set.

The justification for this ABI change was that new fields had been
added to the VFINFO, causing NLM_F_REQUEST messages to fail on systems
with large numbers of VFs if the requesting application didn't have a
large enough buffer for all the info. The idea is that most
applications doing an NLM_F_REQUEST don't care about VFINFO anyway, so
eliminating it from the response would lower the requirements on
buffer size. Apparently, the people who pushed this patch made the
mistaken assumption that iproute2 (the "ip" command) was the only
package that used IFLA_VFINFO_LIST, so it wouldn't break anything else
(and they made sure that iproute2 was fixed.

The logic of this "fix" is debatable at best (one could claim that the
proper fix would be for the applications in question to be fixed so
that they properly sized the buffer, which is what libvirt does
(purely by virtue of using libnl), but it is what it is and we have to
deal with it.

In order for <interface type='hostdev'> to work properly on systems
with a kernel 3.3 or later, libvirt needs to add the afore-mentioned
IFLA_EXT_MASK field with RTEXT_FILTER_VF set.

Of course we also need to continue working on systems with older
kernels, so that one bit of code is compiled conditionally. The one
time this could cause problems is if the libvirt binary was built on a
system without IFLA_EXT_MASK which was subsequently updated to a
kernel that *did* have it. That could be solved by manually providing
the values of IFLA_EXT_MASK and RTEXT_FILTER_VF and adding it to the
message anyway, but I'm uncertain what that might actually do on a
system that didn't support the message, so for the time being we'll
just fail in that case (which will very likely never happen anyway).
(cherry picked from commit ac2797cf)

The first two hunks fix "Unterminated I<...> sequence" error and the
last one fixes "’=item’ outside of any ’=over’" error.
(cherry picked from commit 61299a1c)

https://bugzilla.redhat.com/show_bug.cgi?id=887017 reports that
even though libvirt attempts to set fs.aio-max-nr via sysctl,
the file was installed with the wrong name and gets ignored by
sysctl.  Furthermore, 'man systcl.d' recommends that packages
install into hard-coded /usr/lib/sysctl.d (even when libdir is
/usr/lib64), so that sysadmins can use /etc/sysctl.d for overrides.

* daemon/Makefile.am (install-sysctl, uninstall-sysctl): Use
correct location.
* libvirt.spec.in (network_files): Reflect this.
(cherry picked from commit a1fd56cb)

See also commit 66ff2ddc, where we avoided installing these files
as executables.

* daemon/Makefile.am (libvirtd.service): Drop chmod.
* tools/Makefile.am (libvirt-guests.service): Likewise.
* src/Makefile.am (virtlockd.service, virtlockd.socket):
Likewise.
(cherry picked from commit 5ec4b22b)

Conflicts:
	src/Makefile.am - virtlockd.service not present in 0.10.2

We had several different styles of .in conversion in our Makefiles:
ALLCAPS, @ALLCAPS@, @lower@, ::lower::
Canonicalize on one form, to make it easier to copy and paste
between .in files.

Also, we were using some non-portable sed constructs: \@ is an
undefined escape sequence (it happens to be @ itself in GNU sed,
but POSIX allows it to mean something else), as well as risky
behavior (failure to consistently quote things means a space
in $(sysconfdir) could throw things off; also, Autoconf recommends
using | rather than , or ! in the s||| operator, because | has to
be quoted in shell and is therefore less likely to appear in file
names than , or !).

Fix all of these uses to follow the same syntax.

* daemon/libvirtd.8.in: Switch to @var@.
* tools/virt-xml-validate.in: Likewise.
* tools/virt-pki-validate.in: Likewise.
* src/locking/virtlockd.init.in: Likewise.
* daemon/Makefile.am: Prefer | over ! in sed.
(libvirtd.8): Prefer consistent substitution.
(libvirtd.init, libvirtd.service): Avoid non-portable sed.
* tools/Makefile.am (libvirt-guests.sh, libvirt-guests.init)
(libvirt-guests.service): Likewise.
(virt-xml-validate, virt-pki-validate, virt-sanlock-cleanup):
Prefer consistent capitalization.
* src/Makefile.am (virtlockd.init, virtlockd.service)
(virtlockd.socket): Prefer consistent substitution.
(cherry picked from commit 462a6962)

Conflicts:
	daemon/Makefile.am - drop files not present in 0.10.2
	src/Makefile.am - likewise
	src/locking/virtlockd.init.in - likewise

Most of this deals with moving the libvirt-guests.sh script which
does all the work to /usr/libexec, so it can be shared by both
systemd and traditional init. Previously systemd depended on
the script being in /etc/init.d

Required to fix https://bugzilla.redhat.com/show_bug.cgi?id=789747
(cherry picked from commit d13155c2)

* tools/Makefile.am: Fix tab damage in previous patch.
(cherry picked from commit 07049e4c)

Patch 61299a1c fixed a long-standing pod error in the man page.
But we should be preventing these up front.
See also https://bugzilla.redhat.com/show_bug.cgi?id=870273

* tools/Makefile.am (virt-xml-validate.1, virt-pki-validate.1)
(virt-host-validate.1, virt-sanlock-cleanup.8, virsh.1): Reject
pod conversion errors.
* daemon/Makefile.am ($(srcdir)/libvirtd.8.in): Likewise.
(cherry picked from commit 2639949a)

(cherry picked from commit 0801c149)

Commit dfa1e1dd removed libxenctrl from LIBXL_LIBS, but the libxl
driver uses a symbol from this library.  Explicitly link with
libxenctrl instead of relying on the build system to support
implicit DSO linking.
(cherry picked from commit 68e7bc45)

Based on a patch originally authored by Daniel De Graaf

  http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html

This patch converts the Xen libxl driver to support only Xen >= 4.2.
Support for Xen 4.1 libxl is dropped since that version of libxl is
designated 'technology preview' only and is incompatible with Xen 4.2
libxl.  Additionally, the default toolstack in Xen 4.1 is still xend,
for which libvirt has a stable, functional driver.
(cherry picked from commit dfa1e1dd)

Conflicts:
	src/libxl/libxl_conf.c - commit e5e8d5 not backported
	src/libxl/libxl_driver.c - commit 1c04f999 not backported

This introduces a few new APIs for dealing with strings.
One to split a char * into a char **, another to join a
char ** into a char *, and finally one to free a char **

There is a simple test suite to validate the edge cases
too. No more need to use the horrible strtok_r() API,
or hand-written code for splitting strings.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 76c1fd33)

Conflicts:
	tests/Makefile.am - commit eca72d47 not backported

This patch resolves the problem reported in:

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

The source of the problem was the fix for CVE 2011-3411:

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

which was originally committed upstream in commit
753ff83a. That commit improperly
removed the "--except-interface lo" from dnsmasq commandlines when
--bind-dynamic was used (based on comments in the latter bug).

It turns out that the problem reported in the CVE could be eliminated
without removing "--except-interface lo", and removing it actually
caused each instance of dnsmasq to listen on localhost on port 53,
which created a new problem:

If another instance of dnsmasq using "bind-interfaces" (instead of
"bind-dynamic") had already been started (or if another instance
started later used "bind-dynamic"), this wouldn't have any immediately
visible ill effects, but if you tried to start another dnsmasq
instance using "bind-interfaces" *after* starting any libvirt
networks, the new dnsmasq would fail to start, because there was
already another process listening on port 53.

This patch changes the network driver to *always* add
"except-interface=lo" to dnsmasq conf files, regardless of whether we use
bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances
are listening on localhost (and the CVE is still fixed).

The actual code change is miniscule, but must be propogated through all
of the test files as well.

(This is *not* a cherry-pick of the upstream commit that fixes the bug
(commit d66eb786), because subsequent
to the CVE fix, another patch changed the network driver to put
dnsmasq options in a conf file rather than directly on the dnsmasq
commandline preserving the same options), so a cherry-pick is just one
very large conflict.)

If debugging is enabled, the debug messages are sent to stderr.
Moreover, if a command has catching of stderr set, the messages
gets mixed with stdout output (assuming both outputs are stored
in the same variable). The resulting string then doesn't
necessarily have to start with desired prefix then. This bug
exposes itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06
11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version doesn't
start with expected "Dnsmasq version " string but a libvirt debug
output.
(cherry picked from commit ff33f807)

If the debugging is enabled, the virCommand subsystem catches debug
messages in the command output as well. In that case, we can't assume
the string corresponding to command's stdout will start with specific
prefix. But the prefix can be moved deeper in the string. This bug
shows itself when parsing dnsmasq output:

2012-12-06 11:18:11.445+0000: 18491: error :
dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
/usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000:
18492: debug : virFileClose:72 : Closed fd 22'

We can clearly see that the output of dnsmasq --version
doesn't start with expected "Dnsmasq version " string but a libvirt
debug output.
(cherry picked from commit 51144313)

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

It's odd to fall through to buildVol, and the existed file is
removed when buildVol fails. This checks if the volume target
path already exists in createVol. The reason for not using
error like "Volume already exists" is that there isn't volume
maintained by libvirt for the path until a operation like
pool-refresh, using error like that will just cause confusion.
(cherry picked from commit d1f3d149)

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

Since the virConnect object is not locked wholely when doing
virConenctDispose, a thread can get the lock and thus might
cause the race.

Detected by valgrind:

==23687== Invalid read of size 4
==23687==    at 0x38BAA091EC: pthread_mutex_lock (pthread_mutex_lock.c:61)
==23687==    by 0x3FBA919E36: remoteClientCloseFunc (remote_driver.c:337)
==23687==    by 0x3FBA936BF2: virNetClientCloseLocked (virnetclient.c:688)
==23687==    by 0x3FBA9390D8: virNetClientIncomingEvent (virnetclient.c:1859)
==23687==    by 0x3FBA851AAE: virEventPollRunOnce (event_poll.c:485)
==23687==    by 0x3FBA850846: virEventRunDefaultImpl (event.c:247)
==23687==    by 0x40CD61: vshEventLoop (virsh.c:2128)
==23687==    by 0x3FBA8626F8: virThreadHelper (threads-pthread.c:161)
==23687==    by 0x38BAA077F0: start_thread (pthread_create.c:301)
==23687==    by 0x33F68E570C: clone (clone.S:115)
==23687==  Address 0x4ca94e0 is 144 bytes inside a block of size 312 free'd
==23687==    at 0x4A0595D: free (vg_replace_malloc.c:366)
==23687==    by 0x3FBA8588B8: virFree (memory.c:309)
==23687==    by 0x3FBA86AAFC: virObjectUnref (virobject.c:145)
==23687==    by 0x3FBA8EA767: virConnectClose (libvirt.c:1458)
==23687==    by 0x40C8B8: vshDeinit (virsh.c:2584)
==23687==    by 0x41071E: main (virsh.c:3022)

The above race is caused by the eventLoop thread tries to handle
the net client event by calling the callback set by:
    virNetClientSetCloseCallback(priv->client,
                                 remoteClientCloseFunc,
                                 conn, NULL);

I.E. remoteClientCloseFunc, which lock/unlock the virConnect object.

This patch is to fix the bug by setting the callback to NULL when
doRemoteClose.
(cherry picked from commit b362938e)

The device is still referenced from pcidevs and freeing it would leave
an invalid pointer there.
(cherry picked from commit ea1a9b5f)

Commit 71d12562 tried to fix a problem where rebasing an old
branch on top of newer libvirt.git resulted in automake failing
because of a missing AUTHORS file.  However, while the fix
worked for an incremental 'make', it did not work for someone
that directly reran './autogen.sh'.  Reported by Laine Stump.

* autogen.sh (autoreconf): Check for same conditions as cfg.mk.
* cfg.mk (_update_required): Add comments.
(cherry picked from commit 55dc872b)

Fix the null pointer access when UUID is not specified.
Introduce a bool 'uuidUsable' to virStoragePoolAuthCephx that indicates
if uuid was specified or not and use it instead of the pointless
comparison of the static UUID array to NULL.
Add an error message if both uuid and usage are specified.

Fixes:
Error: FORWARD_NULL (CWE-476):
libvirt-0.10.2/src/conf/storage_conf.c:461: var_deref_model: Passing
    null pointer "uuid" to function "virUUIDParse(char const *, unsigned
    char *)", which dereferences it. (The dereference is assumed on the
    basis of the 'nonnull' parameter attribute.)
Error: NO_EFFECT (CWE-398):
    libvirt-0.10.2/src/conf/storage_conf.c:979: array_null: Comparing an
    array to null is not useful: "src->auth.cephx.secret.uuid != NULL".
(cherry picked from commit bc680e13)

The virNodeSuspend API allows for a duration of 0, to mean no
timed wakup. virsh needlessly forbids this though
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1cad5eba)

When seeing a message

 virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in whitelist

it isn't immediately obvious that 'admin' is the identity
being checked. Quote the string to make it more obvious
(cherry picked from commit 07da0a6b)

detecet by

	http://honk.sigxcpu.org:8001/job/libvirt-build/348/console
(cherry picked from commit d01e427e)

Also removed some unreachable code found by coverity:
libvirt-0.10.2/src/nwfilter/nwfilter_driver.c:259: unreachable: This
code cannot be reached: "nwfilterDriverUnlock(driver...".
(cherry picked from commit 4f9af085)

On error, virStoragePoolGetAutostart would return -1 leaving autostart
untouched.

Removed the misleading debug message as well.

Error: CHECKED_RETURN (CWE-252):
libvirt-0.10.2/tools/virsh-pool.c:1386: unchecked_value: No check of the
    return value of "virStoragePoolGetAutostart(pool, &autostart)".
(cherry picked from commit e9d74a7a)

If allocation of names fails, list is uninitialized.
(cherry picked from commit 892582f9)

On OOM, xdr_destroy got called even though it wasn't created yet.

Found by coverity:
Error: UNINIT (CWE-457):
    libvirt-0.10.2/src/rpc/virnetmessage.c:214: var_decl: Declaring
    variable "xdr" without initializer.
    libvirt-0.10.2/src/rpc/virnetmessage.c:219: cond_true: Condition
    "virReallocN(&msg->buffer, 1UL /* sizeof (*msg->buffer) */,
    msg->bufferLength) < 0", taking true branch
    libvirt-0.10.2/src/rpc/virnetmessage.c:221: goto: Jumping to label
    "cleanup"
    libvirt-0.10.2/src/rpc/virnetmessage.c:257: label: Reached label
    "cleanup"
    libvirt-0.10.2/src/rpc/virnetmessage.c:258: uninit_use: Using
    uninitialized value "xdr.x_ops".
(cherry picked from commit 6e1fc355)

Time values were uninitialized if the connection wasn't usable.
(cherry picked from commit 8b235d40)

Found by coverity:
Error: SIZEOF_MISMATCH (CWE-569):
    libvirt-0.10.2/tools/virsh-domain.c:4754: suspicious_sizeof: Passing
    argument "8UL /* sizeof (cpumap) */" to function
    "_vshCalloc(vshControl *, size_t, size_t, char const *, int)" and
    then casting the return value to "unsigned char *" is suspicious.

Error: SIZEOF_MISMATCH (CWE-569):
    libvirt-0.10.2/tools/virsh-domain.c:4942: suspicious_sizeof: Passing
    argument "8UL /* sizeof (cpumap) */" to function
    "_vshCalloc(vshControl *, size_t, size_t, char const *, int)" and
    then casting the return value to "unsigned char *" is suspicious.
(cherry picked from commit dc04b2a7)

Found by coverity:
Error: REVERSE_INULL (CWE-476):
    libvirt-0.10.2/src/util/processinfo.c:141: deref_ptr: Directly
    dereferencing pointer "map".
    libvirt-0.10.2/src/util/processinfo.c:142: check_after_deref:
    Null-checking "map" suggests that it may be null, but it has already
    been dereferenced on all paths leading to the check.
(cherry picked from commit 7730257d)

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=879473

The name attribute is required for portgroup elements (yes, the RNG
specifies that), and there is code in libvirt that assumes it is
non-null.  Unfortunately, the portgroup parsing function wasn't
checking for lack of portgroup. One adverse result of this was that
attempts to update a network by adding a portgroup with no name would
cause libvirtd to segfault. For example:

   virsh net-update default add portgroup "<portgroup default='yes'/>"

This patch causes virNetworkPortGroupParseXML to fail if no name is
specified, thus avoiding any later problems.
(cherry picked from commit 012d69df)

When starting an LXC guest with a virNetwork based NIC device,
if the network was not active, the virNetworkPtr device would
be leaked
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 509ce943)

In virNetDevVethDelete the virRun method will properly report
errors, but when checking the exit status for non-zero exit
code no error is reported
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 0584d662)

When starting a container, newDef is initialized to a
copy of 'def', but when startup fails newDef is never
removed. This cause later attempts to use 'virDomainDefine'
to lose the new data being defined.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 9d2bfc1c)

A mistaken initialization of 'ret' caused failure to create
macvtap devices to be ignored. The libvirt_lxc process
would later fail to start due to missing devices

Also make sure code checks '< 0' and not '!= 0' since only
-1 is considered an error condition
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 43db9cf4)

If the <interface> device did not contain any <target>
element, LXC would crash on a NULL pointer if starting
the container failed
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 68dceb63)