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>

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>

Conflicts:

	.gitignore

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>

https://bugzilla.redhat.com/show_bug.cgi?id=816662 pointed out
that attempting 'virsh blockpull' on an offline domain gave a
misleading error message about qemu lacking support for the
operation, even when qemu was specifically updated to support it.
The real problem is that we have several capabilities that are
only determined when starting a domain, and therefore are still
clear when first working with an inactive domain (namely, any
capability set by qemuMonitorJSONCheckCommands).

While this patch was able to hoist an existing check in one of the
three culprits, it had to add redundant checks in the other two
places (because you always have to check for an active domain after
obtaining a VM job lock, but the capability bits were being checked
prior to obtaining the job lock).

Someday it would be nice to patch libvirt to cache the set of
capabilities per qemu binary (as determined by inode and timestamp),
rather than re-probing the binary every time a domain is started,
and to teach the cache how to query the monitor during the one
time the probe is made rather than having to wait until a guest
is started; then, a capability probe would succeed even for offline
guests because it just refers to the cache, and the single check for
an active domain after grabbing the job lock would be sufficient.
But since that will involve a lot more coding, I'm happy to go
with this simpler solution for an immediate solution.

* src/qemu/qemu_driver.c (qemuDomainPMSuspendForDuration)
(qemuDomainSnapshotCreateXML, qemuDomainBlockJobImpl): Check for
offline state before checking an online-only cap.

Conflicts:

	src/qemu/qemu_driver.c

This patch addresses the following coverity findings:

/libvirt/src/conf/nwfilter_params.c:390:
var_assigned: Assigning: "varValue" = null return value from "virHashLookup".

/libvirt/src/conf/nwfilter_params.c:392:
dereference: Dereferencing a pointer that might be null "varValue" when calling "virNWFilterVarValueGetNthValue".

/libvirt/src/conf/nwfilter_params.c:399:
dereference: Dereferencing a pointer that might be null "tmp" when calling "virNWFilterVarValueGetNthValue".

This patch addresses the following coverity findings:

/libvirt/src/conf/nwfilter_params.c:157:
deref_parm: Directly dereferencing parameter "val".

/libvirt/src/conf/nwfilter_params.c:473:
negative_returns: Using variable "iterIndex" as an index to array "res->iter".

/libvirt/src/nwfilter/nwfilter_ebiptables_driver.c:2891:
unchecked_value: No check of the return value of "virAsprintf(&protostr, "-d 01:80:c2:00:00:00 ")".

/libvirt/src/nwfilter/nwfilter_ebiptables_driver.c:2894:
unchecked_value: No check of the return value of "virAsprintf(&protostr, "-p 0x%04x ", l3_protocols[protoidx].attr)".

/libvirt/src/nwfilter/nwfilter_ebiptables_driver.c:3590:
var_deref_op: Dereferencing null variable "inst".

Some of the error messages in this function should have been
virReportSystemError (since they have an errno they want to log), but
were mistakenly written as netlinkError, which expects a libvirt error
code instead. The result was that when one of the errors was
encountered, "No error message provided" would be printed instead of
something meaningful (see
https://bugzilla.redhat.com/show_bug.cgi?id=816465 for an example).

Once qemu monitor reports migration has completed, we just closed our
end of the pipe and let migration tunnel die. This generated bogus error
in case we did so before the thread saw EOF on the pipe and migration
was aborted even though it was in fact successful.

With this patch we first wake up the tunnel thread and once it has read
all data from the pipe and finished the stream we close the
filedescriptor.

A small additional bonus of this patch is that real errors reported
inside qemuMigrationIOFunc are not overwritten by virStreamAbort any
more.

When QEMU reported failed or canceled migration, we correctly detected
it but didn't really consider it as an error condition and migration
protocol just went on. Luckily, some of the subsequent steps eventually
failed end we reported an (unrelated and mostly random) error back to
the caller.

Currently, non-blocking calls are either sent immediately or discarded
in case sending would block. This was implemented based on the
assumption that the non-blocking keepalive call is not needed as there
are other calls in the queue which would keep the connection alive.
However, if those calls are no-reply calls (such as those carrying
stream data), the remote party knows the connection is alive but since
we don't get any reply from it, we think the connection is dead.

This is most visible in tunnelled migration. If it happens to be longer
than keepalive timeout (30s by default), it may be unexpectedly aborted
because the connection is considered to be dead.

With this patch, we only discard non-blocking calls when the last call
with a thread is completed and thus there is no thread left to keep
sending the remaining non-blocking calls.

In some cases (spotted with broken connection during tunneled migration)
we were overwriting the original error with worse or even misleading
errors generated when we were cleaning up after failed migration.

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

The function virNetDevMacVLanVPortProfileRegisterCallback() takes an
arg "virtPortProfile", and was checking it for non-NULL before using
it. However, the prototype for
virNetDevMacVLanPortProfileRegisterCallback had marked that arg with
ATTRIBUTE_NONNULL(). Contrary to what one may think,
ATTRIBUTE_NONNULL() does not provide any guarantee that an arg marked
as such really is always non-null; the only effect to the code
generated by gcc, is that gcc *assumes* it is non-NULL; this results
in, for example, the check for a non-NULL value being optimized out.

(Unfortunately, this code removal only occurs when optimization is
enabled, and I am in the habit of doing local builds with optimization
off to ease debugging, so the bug didn't show up in my earlier local
testing).

In general, virPortProfile might always be NULL, so it shouldn't be
marked as ATTRIBUTE_NONNULL. One other function prototype made this
same error, so this patch fixes it as well.

Commit 8fe455fd tried to work around
a regression introduced in upstream gnulib that requires gettext 0.18
or newer on all projects using bootstrap, by making libvirt require
gettext 0.18.  But this fails on RHEL 6.2, which still ships gettext
0.17.  Revert that change, and instead, import the latest round of
gnulib updates that fix that problem properly.

If you have already built in the window where libvirt required 0.18,
be aware that incremental updates may run into problems: this is
because 'autopoint --force' will not downgrade m4/po.m4 back to an
older version, but it must be downgraded back to 0.17 levels to work
with this patch.  You may either manually remove that file then rerun
bootstrap, or it may prove easier to just clean up all non-git files
to start from a clean slate.

* bootstrap.conf: Revert minimum gettext back to 0.17.
* configure.ac: Likewise.
* .gnulib: Update to latest, for bootstrap fixes.
* bootstrap: Resync from gnulib.

Commit c9cd419c added copying of the
makefile for translation files from gnulib. The makefile from gnulib is
of version 0.18 but the build configuration cretes macros from version
0.17 which breaks the build with message:

*** error: gettext infrastructure mismatch: using a Makefile.in.in from
gettext version 0.18 but the autoconf macros are from gettext version
0.17

vboxArray is not castable to a COM item type. vboxArray is a
wrapper around the XPCOM and MSCOM specific array handling.

In this case we can avoid passing NULL as an empty array to
IMachine::Delete by passing a dummy IMedium* array with a single
NULL item.

commit 2223ea98 removes src/libvirt_dbus.syms, but it forgets
to remove it from EXTRA_DIST. It will cause 'make dist' failed.

virThreadSelf tries to access the virThreadPtr stored in TLS for the
current thread via TlsGetValue. When virThreadSelf is called on a thread
that was not created via virThreadCreate (e.g. the main thread) then
TlsGetValue returns NULL as TlsAlloc initializes TLS slots to NULL.

virThreadSelf can be called on the main thread via this call chain from
virsh

vshDeinit
virEventAddTimeout
virEventPollAddTimeout
virEventPollInterruptLocked
virThreadIsSelf

triggering a segfault as virThreadSelf unconditionally dereferences the
return value of TlsGetValue.

Fix this by making virThreadSelf check the TLS slot value for NULL and
setting the given virThreadPtr accordingly.

Reported by Marcel Müller.

Caused by commit 4445e16b that
made the code used the connection private data pointer before
it was initialized.

POSIX says that sa_sigaction is only safe to use if sa_flags
includes SA_SIGINFO; conversely, sa_handler is only safe to
use when flags excludes that bit.  Gnulib doesn't guarantee
an implementation of SA_SIGINFO, but does guarantee that
if SA_SIGINFO is undefined, we can safely define it to 0 as
long as we don't dereference the 2nd or 3rd argument of
any handler otherwise registered via sa_sigaction.

Based on a report by Wen Congyang.

* src/rpc/virnetserver.c (SA_SIGINFO): Stub for mingw.
(virNetServerSignalHandler): Avoid bogus dereference.
(virNetServerFatalSignal, virNetServerNew): Set flags properly.
(virNetServerAddSignalHandler): Drop unneeded #ifdef.

https://bugzilla.redhat.com/show_bug.cgi?id=617711 reported that
even with my recent patched to allow <memory unit='G'>1</memory>,
people can still get away with trying <memory>1G</memory> and
silently get <memory unit='KiB'>1</memory> instead.  While
virt-xml-validate catches the error, our C parser did not.

Not to mention that it's always fun to fix bugs while reducing
lines of code.  :)

* src/conf/domain_conf.c (virDomainParseMemory): Check for parse error.
(virDomainDefParseXML): Avoid strtoll.
* src/conf/storage_conf.c (virStorageDefParsePerms): Likewise.
* src/util/xml.c (virXPathLongBase, virXPathULongBase)
(virXPathULongLong, virXPathLongLong): Likewise.

Commit 78345c68 makes at least gcc 4.1.2 on RHEL 5 complain:

cc1: warnings being treated as errors
In file included from vbox/vbox_V4_0.c:13:
vbox/vbox_tmpl.c: In function 'vboxDomainUndefineFlags':
vbox/vbox_tmpl.c:5298: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

* src/vbox/vbox_tmpl.c (vboxDomainUndefineFlags): Use union to
avoid compiler warning.

Building a fresh checkout on RHEL 5 has been broken since commit
29db7a00, due to a gnulib regression in the bootstrap script
(incremental builds from a checkout earlier than that point were
okay, though).

* .gnulib: Update to latest, for bootstrap fixes.
* bootstrap: Resync from gnulib.
* gnulib/local/top/maint.mk.diff: Drop patch that was added
upstream in the meantime.

Currently upon a migration a callback is created when a 802.1qbg link
is set to PREASSOCIATE, this should not happen because this is a no-op
on most switches, and does not lead to an ASSOCIATE state.  This patch
only creates callbacks when CREATE or RESTORE is requested.  Migration
and libvirtd restart scenarios are already handled elsewhere.
Signed-off-by: ND. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>

The below patch fixes the following memory leak.

==20624== 24 bytes in 2 blocks are definitely lost in loss record 532 of 1,867
==20624==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==20624==    by 0x38EC27FC01: strdup (strdup.c:43)
==20624==    by 0x4EB6BA3: virDomainChrSourceDefCopy (domain_conf.c:1122)
==20624==    by 0x495D76: qemuProcessFindCharDevicePTYs (qemu_process.c:1497)
==20624==    by 0x498321: qemuProcessWaitForMonitor (qemu_process.c:1258)
==20624==    by 0x49B5F9: qemuProcessStart (qemu_process.c:3652)
==20624==    by 0x468B5C: qemuDomainObjStart (qemu_driver.c:4753)
==20624==    by 0x469171: qemuDomainStartWithFlags (qemu_driver.c:4810)
==20624==    by 0x4F21735: virDomainCreate (libvirt.c:8153)
==20624==    by 0x4302BF: remoteDispatchDomainCreateHelper (remote_dispatch.h:852)
==20624==    by 0x4F72C14: virNetServerProgramDispatch (virnetserverprogram.c:416)
==20624==    by 0x4F6D690: virNetServerHandleJob (virnetserver.c:164)
==20624==    by 0x4E8F43D: virThreadPoolWorker (threadpool.c:144)
==20624==    by 0x4E8EAB5: virThreadHelper (threads-pthread.c:161)
==20624==    by 0x38EC606CCA: start_thread (pthread_create.c:301)
==20624==    by 0x38EC2E0C2C: clone (clone.S:115)

Passing a NULL pointer to IMachine::delete virtualbox API
causes VBoxSVC to raise an assertion. This patch passes
an empty array instead.

So that a domain xml which doesn't have "placement" specified, but
"cpuset" is specified, could be parsed. And in this case, the
"placement" mode will be set as "static".

If console[0] is an alias for serial[0], do not enforce the former to
have a PTY source type. This breaks serial consoles on stdio and makes
no sense.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

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>

'omitted' was mispelt 'commited' twice. One of the sentences with
the typo was also missing an 'is' ('each VCPU *is* pinned to all...')
which I added in this commit while I was at it.

It's vznet.conf not vznetctl.conf, see e.g.:

http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetcfg.in;h=e91f5c4a0744c1ea149e1b8c241b666052e10b12;hb=HEAD

lvcreate want's the parent pool's name, not the pool path
lvchange and lvremove want lv specified as $vgname/$lvname

This largely worked before because these commands strip off a
starting /dev. But https://bugzilla.redhat.com/show_bug.cgi?id=714986
is from a user using a 'nested VG' that was having problems.

I couldn't find any info on nested LVM and the reporter never responded,
but I reproduced with XML that specified a valid source name, and
set target path to a symlink.

As explained in previous patch, numad will balance the affinity
dynamically, so reflecting the cpuset from numad at the first
time doesn't make much case, and may just could cause confusion.
(cherry picked from commit 8fb2164c)

Instead of returning a CPUs list, numad returns NUMA node
list instead, this patch is to convert the node list to
cpumap before affinity setting. Otherwise, the domain
processes will be pinned only to CPU[$numa_cell_num],
which will cause significiant performance losses.

Also because numad will balance the affinity dynamically,
reflecting the cpuset from numad back doesn't make much
sense then, and it may just could produce confusion for
the users. Thus the better way is not to reflect it back
to XML. And in this case, it's better to ignore the cpuset
when parsing XML.

The codes to update the cpuset is removed in this patch
incidentally, and there will be a follow up patch to ignore
the manually specified "cpuset" if "placement" is "auto",
and document will be updated too.
(cherry picked from commit ccf80e36)

since this isn't available on older kernels such as Debian Squeeze's
2.6.32. This make --with-macvtap=check work as expected.
(cherry picked from commit a2996926)

The linux-2.6.32 kernel header does not yet define IFLA_VF_MAX and others,
which breaks compiling a new libvirt on old systems like Debian Squeeze.

(I also have to add --without-macvtap --disable-werror --without-virtualport to
 ./configure to get it to compile.)
Signed-off-by: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit d7451bdd)