Having a test that depends on file system timestamps and/or inode
allocation order gives non-deterministic output.

* tests/schematestutils.sh: Run test in deterministic order.

Create a fake PPC64 QEMU so that we can run PPC64 QEMU tests when we
don't have a real version of the emulator available.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

Add logic to assign addresses for devices with spapr-vio addresses.

We also do validation of addresses specified by the user, ie. ensuring
that there are not duplicate addresses on the bus.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

Original patch by Bharata. Updated to use {1,16} in spaprvioReg based
on example from Eric Blake.
Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

For QEMU PPC64 we have a machine type ("pseries") which has a virtual
bus called "spapr-vio". We need to be able to create devices on this
bus, and as such need a way to specify the address for those devices.

This patch adds a new address type "spapr-vio", which achieves this.

The addressing is specified with a "reg" property in the address
definition. The reg is optional, if it is not specified QEMU will
auto-assign an address for the device.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

* tools/virsh.pod: improve virsh man page for domxml-from-native and
domxml-to-native commands.
Signed-off-by: NAlex Jia <ajia@redhat.com>

Detected by valgrind. Leaks introduced in commit 4d5383fd.

* tools/virsh.c: fix memory leaks on cmdDomXMLFromNative and cmdDomXMLToNative.

* how to reproduce?

  % virsh dumpxml ${guest} > foo.xml
  % valgrind -v --leak-check=full virsh domxml-from-native qemu-argv foo.xml
  % valgrind -v --leak-check=full virsh domxml-to-native qemu-argv foo.xml

* actual valgrind results:

==9724== 8,193 bytes in 1 blocks are definitely lost in loss record 31 of 33
==9724==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==9724==    by 0x4A06167: realloc (vg_replace_malloc.c:525)
==9724==    by 0x4C7510B: virReallocN (memory.c:161)
==9724==    by 0x4C84679: virFileReadLimFD (util.c:394)
==9724==    by 0x4C84815: virFileReadAll (util.c:455)
==9724==    by 0x41A89F: cmdDomXMLFromNative (virsh.c:5532)
==9724==    by 0x414872: vshCommandRun (virsh.c:16464)
==9724==    by 0x425623: main (virsh.c:17971)
==9724==
==9724== LEAK SUMMARY:
==9724==    definitely lost: 8,193 bytes in 1 blocks
==9724==    indirectly lost: 0 bytes in 0 blocks
==9724==      possibly lost: 0 bytes in 0 blocks
==9724==    still reachable: 127,128 bytes in 1,347 blocks

==7409== 8,193 bytes in 1 blocks are definitely lost in loss record 31 of 33
==7409==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==7409==    by 0x4A06167: realloc (vg_replace_malloc.c:525)
==7409==    by 0x4C7510B: virReallocN (memory.c:161)
==7409==    by 0x4C84679: virFileReadLimFD (util.c:394)
==7409==    by 0x4C84815: virFileReadAll (util.c:455)
==7409==    by 0x41A7AF: cmdDomXMLToNative (virsh.c:5578)
==7409==    by 0x414892: vshCommandRun (virsh.c:16463)
==7409==    by 0x425633: main (virsh.c:17970)
==7409==
==7409== LEAK SUMMARY:
==7409==    definitely lost: 8,193 bytes in 1 blocks
==7409==    indirectly lost: 0 bytes in 0 blocks
==7409==      possibly lost: 0 bytes in 0 blocks
==7409==    still reachable: 127,128 bytes in 1,347 blocks
Signed-off-by: NAlex Jia <ajia@redhat.com>

Using 'virReallocN' to allocate memory on virConsoleEventOnStdin,
virConsoleEventOnStdout and virConsoleEventOnStream, however, the
cleanup function virConsoleShutdown hasn't released these memory.

* tools/console.c: fix memory leaks on virConsoleShutdown.

https://bugzilla.redhat.com/show_bug.cgi?id=767488Signed-off-by: NAlex Jia <ajia@redhat.com>

Currently non-x86 guests must have <acpi/> defined in <features> to
prevent libvirt from running qemu with -no-acpi. Although it works, it
is a hack.

Instead add a capability flag which indicates whether qemu understands
the -no-acpi option. Use it to control whether libvirt emits -no-acpi.

Current versions of qemu always display -no-acpi in their help output,
so this patch has no effect. However the development version of qemu
has been modified such that -no-acpi is only displayed when it is
actually supported.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

add new command numatune to virsh to get/set numa parameters

Set up the types for the numa functions and insert them into the
virDriver structure definition.

This patch also sets cgroup cpuset parameters for numatune.

The RPC code had several latent memory leaks and an attempt to
free the wrong string, but thankfully nothing triggered them
(blkiotune was the only one returning a string, and always as
the last parameter).  Also, our cleanups for rpcgen ended up
nuking a line of code that renders VIR_TYPED_PARAM_INT broken,
because it was the only use of 'i' in a function, even though
it was a member usage rather than a standalone declaration.

* daemon/remote.c (remoteSerializeTypedParameters): Free the
correct array element.
(remoteDispatchDomainGetSchedulerParameters)
(remoteDispatchDomainGetSchedulerParametersFlags)
(remoteDispatchDomainBlockStatsFlags)
(remoteDispatchDomainGetMemoryParameters): Don't leak strings.
* src/rpc/genprotocol.pl: Don't nuke member-usage of 'buf' or 'i'.

No need to repeat code for formatting typed parameters.

* tools/virsh.c (vshGetTypedParamValue): Support strings, and exit
on OOM.
(cmdSchedinfo, cmdBlkiotune, cmdMemtune, cmdBlkdeviotune): Use
it for less code.

Even though we technically don't support <qemu:commandline> (as in,
if you mis-use things, you get to keep the pieces), we should at
least document how to use it.

[See also http://berrange.com/posts/2011/12/19/using-command-line-arg-monitor-command-passthrough-with-libvirt-and-kvm/]

* docs/drvqemu.html.in (qemucommand): New section.

* Detected by valgrind. Leak introduced in commit 5ab109f8.

* python/libvirt-override.c: avoid memory leak on libvirt_virConnectOpenAuth.

* How to reproduce?

  % valgrind -v --leak-check=full virt-clone --print-xml
  Note: it can hit the issue although options are incomplete.

* Actual valgrind result:

==1801== 12 bytes in 1 blocks are definitely lost in loss record 25 of 3,270
==1801==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==1801==    by 0xCF1F60E: libvirt_virConnectOpenAuth (libvirt-override.c:1507)
==1801==    by 0x3AFEEDE7F3: PyEval_EvalFrameEx (ceval.c:3794)
==1801==    by 0x3AFEEDF99E: PyEval_EvalFrameEx (ceval.c:3880)
==1801==    by 0x3AFEEDF99E: PyEval_EvalFrameEx (ceval.c:3880)
==1801==    by 0x3AFEEDF99E: PyEval_EvalFrameEx (ceval.c:3880)
==1801==    by 0x3AFEEDF99E: PyEval_EvalFrameEx (ceval.c:3880)
==1801==    by 0x3AFEEE0466: PyEval_EvalCodeEx (ceval.c:3044)
==1801==    by 0x3AFEEE0541: PyEval_EvalCode (ceval.c:545)
==1801==    by 0x3AFEEFB88B: run_mod (pythonrun.c:1351)
==1801==    by 0x3AFEEFB95F: PyRun_FileExFlags (pythonrun.c:1337)
==1801==    by 0x3AFEEFCE4B: PyRun_SimpleFileExFlags (pythonrun.c:941)
Signed-off-by: NAlex Jia <ajia@redhat.com>

Remove 2 words that shouldn't be here.

The lifetime of the virDomainEventState object is tied to
the lifetime of the driver, which in stateless drivers is
tied to the lifetime of the virConnectPtr.

If we add & remove a timer when allocating/freeing the
virDomainEventState object, we can get a situation where
the timer still triggers once after virDomainEventState
has been freed. The timeout callback can't keep a ref
on the event state though, since that would be a circular
reference.

The trick is to only register the timer when a callback
is registered with the event state & remove the timer
when the callback is unregistered.

The demo for the bug is to run

  while true ; do date ; ../tools/virsh -q -c test:///default 'shutdown test; undefine test; dominfo test' ; done

prior to this fix, it will frequently hang and / or
crash, or corrupt memory

Currently all drivers using domain events need to provide a callback
for handling a timer to dispatch events in a clean stack. There is
no technical reason for dispatch to go via driver specific code. It
could trivially be dispatched directly from the domain event code,
thus removing tedious boilerplate code from all drivers

Also fix the libxl & xen drivers to pass 'true' when creating the
virDomainEventState, since they run inside the daemon & thus always
expect events to be present.

* src/conf/domain_event.c, src/conf/domain_event.h: Internalize
  dispatch of events from timer callback
* src/libxl/libxl_driver.c, src/lxc/lxc_driver.c,
  src/qemu/qemu_domain.c, src/qemu/qemu_driver.c,
  src/remote/remote_driver.c, src/test/test_driver.c,
  src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
  src/xen/xen_driver.c: Remove all timer dispatch functions

The virDomainEventCallbackList and virDomainEventQueue APIs are
now solely helpers used internally by virDomainEventState APIs.
Remove their decls from domain_event.h since no driver code should
need to use them any more.

* src/conf/domain_event.c: Make virDomainEventCallbackList and
  virDomainEventQueue APIs static & remove some unused APIs
* src/conf/domain_event.h, src/libvirt_private.syms: Remove
  virDomainEventCallbackList and virDomainEventQueue APIs

No caller of the domain events APIs should need to poke at the
struct internals. Thus they should all be removed from the
header file

* src/conf/domain_event.h: Remove struct definitions
* src/conf/domain_event.c: Add struct definitions

* src/libxl/libxl_driver.c, src/lxc/lxc_driver.c,
  src/qemu/qemu_driver.c, src/remote/remote_driver.c,
  src/test/test_driver.c, src/uml/uml_driver.c,
  src/vbox/vbox_tmpl.c, src/xen/xen_driver.c: Convert
  to threadsafe APIs

While virDomainEventState has APIs for managing removal of callbacks,
while locked, adding callbacks in the first place requires direct
access to the virDomainEventCallbackList structure. This is not
threadsafe since it is bypassing the virDomainEventState locks

* src/conf/domain_event.c, src/conf/domain_event.h,
  src/libvirt_private.syms: Add APIs for managing callbacks
  via virDomainEventState.

When registering a callback for a particular event some callers
need to know how many callbacks already exist for that event.
While it is possible to ask for a count, this is not free from
race conditions when threaded. Thus the API for registering
callbacks should return the count of callbacks. Also rename
virDomainEventStateDeregisterAny to virDomainEventStateDeregisterID

* src/conf/domain_event.c, src/conf/domain_event.h,
  src/libvirt_private.syms: Return count of callbacks when
  registering callbacks
* src/libxl/libxl_driver.c, src/libxl/libxl_driver.c,
  src/qemu/qemu_driver.c, src/remote/remote_driver.c,
  src/remote/remote_driver.c, src/uml/uml_driver.c,
  src/vbox/vbox_tmpl.c, src/xen/xen_driver.c: Update
  for change in APIs

The Xen & VBox drivers deal with callbacks & dispatching of
events directly. All the other drivers use a timer to dispatch
events from a clean stack state, rather than deep inside the
drivers. Convert Xen & VBox over to virDomainEventState so
that they match behaviour of other drivers

* src/conf/domain_event.c: Return count of remaining
  callbacks when unregistering event callback
* src/vbox/vbox_tmpl.c, src/xen/xen_driver.c,
  src/xen/xen_driver.h: Convert to virDomainEventState

If only iptables rules are created then two unnecessary ebtables chains
are also created. This patch fixes this and prevents these chains from
being created. They have been cleaned up properly, though.

Using dtrace (and systemtap in general) is Linux-specific.
Running ./autobuild.sh shows that attempting a cross-build to
target mingw was mistakenly trying to build dtrace code, merely
because it was present on the compilation host.

* configure.ac (with_dtrace): Don't attempt to use dtrace when
doing a cross-build hosted on Linux but targetting elsewhere.
Reported by Daniel P. Berrange.

A generic error code was returned, if the user aborted a migration job.
This made it hard to distinguish between a user requested abort and an
error that might have occured. This patch introduces a new error code,
which is returned in the specific case of a user abort, while leaving
all other failures with their existing code. This makes it easier to
distinguish between failure while mirgrating and an user requested
abort.

 * include/libvirt/virterror.h: - add new error code
 * src/util/virterror.c: - add message for the new error code
 * src/qemu/qemu_migration.h: - Emit operation aborted error instead of
                                operation failed, on migration abort

If managed save fails at the right point in time, then the save
image can end up with 0 bytes in length (no valid header), and
our attempts in commit 55d88def to detect and skip invalid save
files missed this case.

* src/qemu/qemu_driver.c (qemuDomainSaveImageOpen): Also unlink
empty file as corrupt.  Reported by Dennis Householder.

Currently, on device detach, we parse given XML, find the device
in domain object, free it and try to restore security labels.
However, in some cases (e.g. usb hostdev) parsed XML contains
less information than freed device. In usb case it is bus & device
IDs. These are needed during label restoring as a symlink into
/dev/bus is generated from them. Therefore don't drop device
configuration until security labels are restored.

Add an option for virsh undefine command, to remove associated storage
volumes while undefining a domain. This patch allows the user to remove
associated (libvirt managed ) storage volumes while undefining a domain.

The new option --storage for the undefine command takes a string
argument that consists of comma separated list of target or source path
of volumes to be undefined. Volumes are removed after the domain has
been successfully undefined,

If a volume is not part of a storage pool, the user is warned to remove
the volume in question himself.

Option --wipe-storage may be specified along with this, that ensures
the image is wiped before removing.

Option --remove-all-storage enables the user to remove all storage. The
name is chosen long as the users should be aware what they're about to
do.

Some gcc warnings about no % in a printf format string only
appear under --disable-nls.  And configure.ac should automatically
be excluding modules on mingw without us having to be explicit.
Improving autobuild.sh to stress more combinations can only help.

* autobuild.sh: Add --disable-nls on first build.  Update mingw
build to rely more on configure.ac detection.

In commit 6f84e110 I mistakenly set default migration speed to
33554432 Mb!  The units of migMaxBandwidth is Mb, with conversion
handled in qemuMonitor{JSON,Text}SetMigrationSpeed().

Also, remove definition of QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX since
it is no longer used after reverting commit ef1065cf.

A simple example to show how to use it:

\#! /usr/bin/python

import os
import sys
import libvirt

disk = "/var/lib/libvirt/images/test.img"

conn = libvirt.open(None)
dom = conn.lookupByName('test')

mem_contents = dom.memoryPeek(0, 32, libvirt.VIR_MEMORY_VIRTUAL);
sys.stdout.write(mem_contents)

% python test.py | hexdump
0000000 1660 0209 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 d3a0 01d0 0000 0000
0000020

If an async job run on a domain will stop the domain at the end of the
job, a concurrently run query job can hang in qemu monitor and nothing
can be done with that domain from this point on. An attempt to start
such domain results in "Timed out during operation: cannot acquire state
change lock" error.

However, quite a few things have to happen at the right time... There
must be an async job running which stops a domain at the end. This race
was reported with dump --crash but other similar jobs, such as
(managed)save and migration, should be able to trigger this bug as well.
While this async job is processing its last monitor command, that is a
query-migrate to which qemu replies with status "completed", a new
libvirt API that results in a query job must arrive and stay waiting
until the query-migrate command finishes. Once query-migrate is done but
before the async job closes qemu monitor while stopping the domain, the
other thread needs to wake up and call qemuMonitorSend to send its
command to qemu. Before qemu gets a chance to respond to this command,
the async job needs to close the monitor. At this point, the query job
thread is waiting for a condition that no-one will ever signal so it
never finishes the job.

* src/qemu/qemu_hostdev.c (qemuDomainReAttachHostdevDevices):
pciDeviceListFree(pcidevs) in the end free()s the device even if
it's in use by other domain, which can cause a race.

How to reproduce:

<script>

virsh nodedev-dettach pci_0000_00_19_0
virsh start test
virsh attach-device test hostdev.xml
virsh start test2

for i in {1..5}; do
        echo "[ -- ${i}th time --]"
        virsh nodedev-reattach pci_0000_00_19_0
done

echo "clean up"
virsh destroy test
virsh nodedev-reattach pci_0000_00_19_0
</script>

Device pci_0000_00_19_0 dettached

Domain test started

Device attached successfully

error: Failed to start domain test2
error: Requested operation is not valid: PCI device 0000:00:19.0 is in use by domain test

[ -- 1th time --]
Device pci_0000_00_19_0 re-attached

[ -- 2th time --]
Device pci_0000_00_19_0 re-attached

[ -- 3th time --]
Device pci_0000_00_19_0 re-attached

[ -- 4th time --]
Device pci_0000_00_19_0 re-attached

[ -- 5th time --]
Device pci_0000_00_19_0 re-attached

clean up
Domain test destroyed

Device pci_0000_00_19_0 re-attached

The patch also fixes another problem, there won't be error like
"qemuDomainReAttachHostdevDevices: Not reattaching active
device 0000:00:19.0" in daemon log if some device is in active.
As pciResetDevice and pciReattachDevice won't be called for
the device anymore. This is sensible as we already reported
error when preparing the device if it's active. Blindly trying
to pciResetDevice & pciReattachDevice on the device and getting
an error is just redundant.