Done mechanically with:
$ git grep -l '\bDEBUG0\? *(' | xargs -L1 sed -i 's/\bDEBUG0\? *(/VIR_&/'

followed by manual deletion of qemudDebug in daemon/libvirtd.c, along
with a single 'make syntax-check' fallout in the same file, and the
actual deletion in src/util/logging.h.

* src/util/logging.h (DEBUG, DEBUG0): Delete.
* daemon/libvirtd.h (qemudDebug): Likewise.
* global: Change remaining clients over to VIR_DEBUG counterpart.

Two-argument free functions are uncommon; match the style elsewhere
by caching the callback at creation.

* src/util/hash.h (virHashCreate, virHashFree): Move deallocator
argument to creation.
* cfg.mk (useless_free_options): Add virHashFree.
* src/util/hash.c (_virHashTable): Track deallocator.
(virHashCreate, virHashFree): Update to new signature.
* src/conf/domain_conf.c (virDomainObjListDeinit)
(virDomainObjListInit, virDomainDiskDefForeachPath)
(virDomainSnapshotObjListDeinit, virDomainSnapshotObjListInit):
Update callers.
* src/conf/nwfilter_params.c (virNWFilterHashTableFree)
(virNWFilterHashTableCreate): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterTriggerVMFilterRebuild):
Likewise.
* src/cpu/cpu_generic.c (genericHashFeatures, genericBaseline):
Likewise.
* src/xen/xm_internal.c (xenXMOpen, xenXMClose): Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnInit)
(virNWFilterLearnShutdown): Likewise.
* src/qemu/qemu_command.c (qemuDomainPCIAddressSetCreate)
(qemuDomainPCIAddressSetFree): Likewise.
* src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise.

The virConnectPtr struct will cache instances of all other
objects. APIs like virDomainLookupByUUID will return a
cached object, so if you do virDomainLookupByUUID twice in
a row, you'll get the same exact virDomainPtr instance.

This does not have any performance benefit, since the actual
logic in virDomainLookupByUUID (and other APIs returning
virDomainPtr, etc instances) is not short-circuited. All
it does is to ensure there is only one single virDomainPtr
in existance for any given UUID.

The caching has a number of downsides though, all relating
to stale data. If APIs aren't careful to always overwrite
the 'id' field in virDomainPtr it may become out of data.
Likewise for the name field, if a guest is renamed, or if
a guest is deleted, and then a new one created with the
same UUID but different name.

This has been an ongoing, endless source of bugs for all
applications using libvirt from languages with garbage
collection, causing them to get virDomainPtr instances
from long ago with stale data.

The caching is also a waste of memory resources, since
both applications, and language bindings often maintain
their own hashtable caches of object instances.

This patch removes all the hash table caching, so all
APIs return brand new virDomainPtr (etc) object instances.

* src/datatypes.h: Delete all hash tables.
* src/datatypes.c: Remove all object caching code

This patch adds the possibility to not just drop packets, but to also have them rejected where iptables at least sends an ICMP msg back to the originator. On ebtables this again maps into dropping packets since rejecting is not supported.

I am adding 'since 0.8.9' to the docs assuming this will be the next version of libvirt.

since dnsmasq >= 2.56 now bails out with empty arguments. See
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613944
for the Debian bug and
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589885
for the upstream reasoning.

Two regressions:
Commit df1011ca broke builds for systems that lack devmapper
(non-Linux, as well as Linux with ./autogen.sh --without-libvirtd
and without the libraries present).
Commit ce6fd650 broke cross-compilation, due to a gnulib bug.

* .gnulib: Update to latest, for cross-compilation fix.
* src/util/util.c (virIsDevMapperDevice): Provide stub for
platforms not using storage driver.
* configure.ac (devmapper): Arrange to define HAVE_LIBDEVMAPPER_H.
devmapper issue reported by Wen Congyang.

Etienne Gosset reported that libvirt fails to connect to his ESX
server because it failed to parse its malformed host UUID, that
contains an additional space and lacks one hexdigit in the last
group:

xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxx

Don't treat this as a fatal error, just ignore it.

Virsh freecell --all was not only getting wrong NUMA nodes count, but
even the NUMA nodes IDs. They doesn't have to be continuous, as I've
found out during testing this. Therefore a modification of
nodeGetCellsFreeMemory() error message.

$ ./configure
...
$ make
...
  GEN    libvirt.syms
...
$ ./configure --with-driver-modules
...
$ make
...

libvirt.syms doesn't get regenerated but it should as it should
contain virDriverLoadModule now.

* src/Makefile.am (libvirt.syms): Depend on configure changes.
Reported by Matthias Bolte.

libvirt-tck was failing several domain tests [1] with qemu 0.14, which
is now less tolerable of specifying 2 bootroms with the same boot index [2].

Drop the 'boot=on' param if kernel has been specfied.

[1] https://www.redhat.com/archives/libvir-list/2011-February/msg00559.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg01892.html

There were several occurrences of an extra space inserted between
a function name and the ( opening the argument list in
datatypes.c. This is not consistent with the coding style used in
the rest of this file so removing this extra space makes the
code slightly more readable.

virHashFree follows the convention described in HACKING that
XXXFree() functions can be called with a NULL argument.

Now that the virHash handling functions call virReportOOMError by
themselves when needed, users of the virHash API no longer need to
do it by themselves. Since users of the virHash API were not
consistently calling virReportOOMError after memory failures from
the virHash code, this has the added benefit of making OOM
reporting from this code more consistent and reliable.

The only difference between these 2 functions is that one errors
out when the entry is already present while the other modifies
the existing entry. Add an helper function with a boolean argument
indicating whether existing entries should be updated or not, and
use this helper in both functions.

The code in virHashUpdateEntry and virHashAddEntry is really
similar. However, the latter rebalances the hash table when
one of its buckets contains too many elements while the former
does not. Fix this discrepancy.

* src/util/hash.c (virHashGrow) [DEBUG_GROW]: Use modern logging.
Reported by Christophe Fergeau.

When we attach a disk, but we specify a wrong format of disk image,
qemu monitor command drive_add will fail, but libvirt does not detect
this error.
Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>

Followup to commit 17e19add, and would have prevented the bug
independently fixed in commit 76c57a7c.

* src/util/logging.c (virLogMessage): Preserve errno, since
logging should be as unintrusive as possible.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463

The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".

The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).

Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.

I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.

Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).

docs/formatnetwork.html.in: document <mac address.../>
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format <mac address.../>
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
    auto-generate mac address when needed,
    create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests

An upcoming patch has a use for a tap device to be created that
doesn't need to be actually put into the "up" state, and keeping it
"down" keeps the output of ifconfig from being unnecessarily cluttered
(ifconfig won't show down interfaces unless you add "-a").

bridge.[ch]: add "up" as an arg to brAddTap()
uml_conf.c, qemu_command.c: add "up" (set to "true") to brAddTap() call.

This is in response to:

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

Explanation

qemu's virtio-net-pci driver allows setting the algorithm used for tx
packets to either "bh" or "timer". This is done by adding ",tx=bh" or
",tx=timer" to the "-device virtio-net-pci" commandline option.

'bh' stands for 'bottom half'; when this is set, packet tx is all done
in an iothread in the bottom half of the driver. (In libvirt, this
option is called the more descriptive "iothread".)

'timer' means that tx work is done in qemu, and if there is more tx
data than can be sent at the present time, a timer is set before qemu
moves on to do other things; when the timer fires, another attempt is
made to send more data. (libvirt retains the name "timer" for this
option.)

The resulting difference, according to the qemu developer who added
the option is:

    bh makes tx more asynchronous and reduces latency, but potentially
    causes more processor bandwidth contention since the cpu doing the
    tx isn't necessarily the cpu where the guest generated the
    packets.

Solution

This patch provides a libvirt domain xml knob to change the option on
the qemu commandline, by adding a new attribute "txmode" to the
<driver> element that can be placed inside any <interface> element in
a domain definition. It's use would be something like this:

    <interface ...>
      ...
      <model type='virtio'/>
      <driver txmode='iothread'/>
      ...
    </interface>

I chose to put this setting as an attribute to <driver> rather than as
a sub-element to <tune> because it is specific to the virtio-net
driver, not something that is generally usable by all network drivers.
(note that this is the same placement as the "driver name=..."
attribute used to choose kernel vs. userland backend for the
virtio-net driver.)

Actually adding the tx=xxx option to the qemu commandline is only done
if the version of qemu being used advertises it in the output of

    qemu -device virtio-net-pci,?

If a particular txmode is requested in the XML, and the option isn't
listed in that help output, an UNSUPPORTED_CONFIG error is logged, and
the domain fails to start.

When the <driver> element (and its "name" attribute) was added to the
domain XML's interface element, a "backend" enum was simply added to
the toplevel of the virDomainNetDef struct.

Ignoring the naming inconsistency ("name" vs. "backend"), this is fine
when there's only a single item contained in the driver element of the
XML, but doesn't scale well as we add more attributes that apply to
the backend of the virtio-net driver, or add attributes applicable to
other drivers.

This patch changes virDomainNetDef in two ways:

1) Rename the item in the struct from "backend" to "name", so that
   it's the same in the XML and in the struct, hopefully avoiding
   confusion for someone unfamiliar with the function of the
   attribute.

2) Create a "driver" union within virDomainNetDef, and a "virtio"
   struct in that struct, which contains the "name" enum value.

3) Move around the virDomainNetParse and virDomainNetFormat functions
   to allow for simple plugin of new attributes without disturbing
   existing code. (you'll note that this results in a seemingly
   redundant if() in the format function, but that will no longer be
   the case as soon as a 2nd attribute is added).

In the future, new attributes for the virtio driver backend can be
added to the "virtio" struct, and any other network device backend that
needs an attribute will have its own struct added to the "driver"
union.

The introduction of the v3 migration protocol, along with
support for migration cookies, will significantly expand
the size of the migration code. Move it all to a separate
file to make it more manageable

The functions are not moved 100%. The API entry points
remain in the main QEMU driver, but once the public
virDomainPtr is resolved to the internal virDomainObjPtr,
all following code is moved.

This will allow the new v3 API entry points to call into the
same shared internal migration functions

* src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Add
  qemuDomainFormatXML helper method
* src/qemu/qemu_driver.c: Remove all migration code
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Add
  all migration code.

Move the qemudStartVMDaemon and qemudShutdownVMDaemon
methods into a separate file, renaming them to
qemuProcessStart, qemuProcessStop. All helper methods
called by these are also moved & renamed to match

* src/Makefile.am: Add qemu_process.c/.h
* src/qemu/qemu_command.c: Add qemuDomainAssignPCIAddresses
* src/qemu/qemu_command.h: Add VNC port min/max
* src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Add
  domain event queue helpers
* src/qemu/qemu_driver.c, src/qemu/qemu_driver.h: Remove
  all QEMU process startup/shutdown functions
* src/qemu/qemu_process.c, src/qemu/qemu_process.h: Add
  all QEMU process startup/shutdown functions

The name convention of device mapper disk is different, and 'parted'
can't be used to delete a device mapper disk partition. e.g.

Name                 Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1

Error: Expecting a partition number.

This patch introduces 'dmsetup' to fix it.

Changes:
  - New function "virIsDevMapperDevice" in "src/utils/utils.c"
  - remove "is_dm_device" in "src/storage/parthelper.c", use
    "virIsDevMapperDevice" instead.
  - Requires "device-mapper" for 'with-storage-disk" in "libvirt.spec.in"
  - Check "dmsetup" in 'configure.ac' for "with-storage-disk"
  - Changes on "src/Makefile.am" to link against libdevmapper
  - New entry for "virIsDevMapperDevice" in "src/libvirt_private.syms"

Changes from v1 to v3:
  - s/virIsDeviceMapperDevice/virIsDevMapperDevice/g
  - replace "virRun" with "virCommand"
  - sort the list of util functions in "libvirt_private.syms"
  - ATTRIBUTE_NONNULL(1) for virIsDevMapperDevice declaration.

e.g.

Name                 Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1

Vol /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 deleted

Name                 Path
-----------------------------------------

"qemudDomainSaveFlag" goto wrong label "endjob", which will cause
error when security manager trying to restore label (regression).

As it's more reasonable to check if vm is shutoff immediately, and
return right away if it is, remove the checking in "qemudDomainSaveFlag",
and add checking in "qemudDomainSave".

* src/qemu/qemu_driver.c

* src/util/cgroup.c (virCgroupSetValueStr, virCgroupGetValueStr)
(virCgroupRemoveRecursively): VIR_DEBUG can clobber errno.
(virCgroupRemove): Use VIR_DEBUG rather than DEBUG.

The code expected that host CPU architecture matches the architecture on
which libvirt runs. This is normally true but not in tests, where host
CPU is faked to produce consistent results.

* docs/drvopenvz.html.in: Spell administrator correctly.
* docs/drvuml.html.in: Likewise.
* src/qemu/qemu.conf: Likewise.  Fix other typos, too.

clang had 5 reports against virCommand; three were false positives
(a NULL deref in ProcessIO solved by sa_assert, and two uninitialized
memory operations solved by adding an initializer), but two were real.

* src/util/command.c (virCommandProcessIO): Fix real bug of
possible NULL dereference.  Teach clang that buf is never NULL.
(virCommandRun): Teach clang that infd is only ever accessed when
initialized.

* src/qemu/qemu_command.c (qemuBuildCommandLine): Don't report oom
after qemuBuildControllerDevStr, which reported its own errors.

The processWatchdogEvent fix is real, although it can only trigger
on OOM, since bad things happen if doCoreDump is called with a NULL
pathname argument.  The other fixes silence clang, but aren't a real
bug because virReportErrorHelper tolerates a NULL format string even
though *printf does not.

* src/qemu/qemu_driver.c (processWatchdogEvent): Exit on OOM.
(qemuDomainIsActive, qemuDomainIsPersistent, qemuDomainIsUpdated):
Provide valid message.

* src/libvirt.c (virDomainMemoryStats): Check domain before flags.

* src/util/threads-pthread.c: Fix mutex leak

The SCSI storage backend leaks a string containing the pathname
for each block device it discovers

* src/storage/storage_backend_scsi.c: Free the device name

This helps identifying which command exited with status != 0.

When creating the virDomain::snapshots hash table, virGetDomain
wasn't checking if the creation was successful. This would then
lead to failures in the vir*DomainSnapshot functions. Better to
report this error early and make virGetDomain fail if the
snapshots hash couldn't be created.
* src/datatypes.c: report failure to make a hash table

A couple of allocation were not calling virReportOOMError on allocation
errors

* src/util/hash.c: add the needed call in virHashCreate and
  virHashAddOrUpdateEntry

"virStorageBackendCreateVols":
  "names->next" serves as condition expression for "do...while",
however, "names" was shifted before, it then results in one less
loop, and thus, one less volume will be created for mpath pool,
the patch is to fix it.

* src/storage/storage_backend_mpath.c