build: avoid non-portable byte-swapping

Commit 0fc89098 used functions only available on glibc, completely
botched 32-bit environments, and risked SIGBUS due to unaligned
memory access on platforms that aren't as forgiving as x86_64.

* bootstrap.conf (gnulib_modules): Import ffsl.
* src/util/bitmap.c (includes): Use <strings.h> for ffsl.
(virBitmapNewData, virBitmapToData): Avoid 64-bit assumptions and
non-portable functions.

Fix minor details not only in apic eoi

The introduction of APIC EOI patches had a few little details that
could look better, so this patch fixes that and one more place in the
file as well (same problem).

secret: Fix error for private secrets

When trying to get the value of a private secret, the code used
'operation denied' error. That error is specified as a error for
read-only connections trying to perform denied operation. The
following error seems more accurate.

To compare the difference:
 - BEFORE
error: operation secret is private forbidden for read only access

 - AFTER
error: Invalid secret: secret is private

virNetDevBandwidthClear: Improve error handling

Two changes are introduced in this patch:

 - The first change removes ATTRIBUTE_RETURN_CHECK from
   virNetDevBandwidthClear, because it was called with ignore_value
   always, anyway. The function is used even when it's not necessary
   to call it, just for cleanup purposes.

 - The second change is added ignoring of the command's exit status,
   since it may report an error even when run just as "to be sure we
   clean up" function. No libvirt errors are suppresed by this.

syntax-check: fix run.in

Two more problems in "run.in" made the syntax-check fail.

Adhere to copyright_address check

to fix "make syntax-check"

Found by http://honk.sigxcpu.org:8001/job/libvirt-syntax-check/

Add a ./run script for running programs from the local directory.

With this script you can run libvirt programs without needing to
install them first.  You just have to do for example:

  ./run ./tools/virsh [args ...]

If you are already in the tools/ subdirectory, then the following
command will also work:

  ../run ./virsh [...]

You can also run the C programs under valgrind like this:

  ./run valgrind [valgrind opts...] ./program

or under gdb:

  ./run gdb --args ./program

This also works with sudo (eg. if you need root access for libvirt):

  sudo ./run ./tools/virsh list --all

Derived from libguestfs and simplified.  The ./run script in
libguestfs is much more sophisticated:

https://github.com/libguestfs/libguestfs/blob/master/run.in

rpc: Fix name of member in remote_protocol-structs

Commit 7a99b0abafb69e1686198ac3473892a9aaeb8255 adds a new RPC struct
but one of the members has different names in remote_protocol.x and
remote_protocol-struct breaking make check.

virBitmap: fix build without HAVE_NUMACTL

Commit 75b198b3e7b2c8b4106afbd42f8bb795c4773511 forgot to change
arguments of dummy qemuProcessInitNumaMemoryPolicy from char* to
virBitmapPtr.

qemuhelptest: convert runaway tab to spaces

Make syntax-check happy and smiling again.

daemon: Fix error message when libvirtd is missing.

Currently we search along the hard-coded names:
  SBINDIR "/libvirtd"
  SBINDIR "/libvirtd_dbg"
but if the environment variable $LIBVIRTD_PATH is set to the
name of the libvirtd binary, that is used instead.  Fix the
error message so it accurately reflects current behaviour
($PATH is NOT searched).

gitignore: Ignore .gdb_history file.

Fix the augea test for qemu libvirtd options

Commit 1ccf22277be013beb3f26f0083867c9c9eddca18 forgot to
add the output to the augeas test

network: implement backend of virNetworkUpdate(IP_DHCP_HOST)

This patch fills in the first implementation for one of the
virNetworkUpdate sections. With this code, you can now add/delete/edit
<host> entries in a network's <ip> address <dhcp> element (by
specifying a section of VIR_NETWORK_SECTION_IP_DHCP_HOST).

If you pass in a parentIndex of -1, the code will automatically find
the one ip element that has a <dhcp> section and make the updates
there. Otherwise, you can specify an index >= 0, and libvirt will look
for that particular instance of <ip> in the network, and modify its
<dhcp> element. (This currently isn't very useful, because libvirt
only supports having dhcp information on a single IP address, but that
could change in the future).

When adding a new host entry
(VIR_NETWORK_UPDATE_COMMAND_ADD_(FIRST|LAST)), the existing entries
will be compared to the new entry, and if any non-empty attribute
matches, the add will fail. When updating an existing entry
(VIR_NETWORK_UPDATE_COMMAND_MODIFY), the mac address or name will be
used to find the existing entry, and other fields will only be updated
(note there is some potential for ambiguity here if you specify the
mac address from one entry and the name from another).  When deleting
an existing entry (VIR_NETWORK_UPDATE_COMMAND_DELETE), all non-empty
attributes in the supplied xml arg will be compared - all of them must
match before libvirt will delete the host.

The xml should be a fully formed <host> element as it would appear in
a network definition, e.g. "<host mac=00:11:22:33:44:55 ip=10.1.23.22
name='testbox'/>" (when adding/updating, ip and one of mac|name is
required; when deleting, you can specify any one, two, or all
attributes, but they all must match the target element).

As with the update of any other section, you can choose to affect the
live config (with flag VIR_NETWORK_UPDATE_AFFECT_LIVE), the persistent
config (VIR_NETWORK_UPDATE_AFFECT_CONFIG), or both. If you've chosen
to affect the live config, those changes will take effect immediately,
with no need to destroy/restart the network.

An example of adding a host entry:

   virNetworkUpdate(net, VIR_NETWORK_UPDATE_COMMAND_ADD_LAST,
                     VIR_NETWORK_SECTION_IP_DHCP_HOST, -1,
                    "<host mac='00:11:22:33:44:55' ip='192.168.122.5'/>",
                    VIR_NETWORK_UPDATE_AFFECT_LIVE
                    | VIR_NETWORK_UPDATE_AFFECT_CONFIG);

To delete that same entry:

   virNetworkUpdate(net, VIR_NETWORK_UPDATE_COMMAND_DELETE,
                    VIR_NETWORK_SECTION_IP_DHCP_HOST, -1,
                    "<host mac='00:11:22:33:44:55'/>",
                    VIR_NETWORK_UPDATE_AFFECT_LIVE
                    | VIR_NETWORK_UPDATE_AFFECT_CONFIG);

(you could also delete it by replacing "mac='00:11:22:33:44:55'" with
"ip='192.168.122.5'".)

network: restart radvd/dnsmasq if needed when libvirtd is restarted

A user on IRC had accidentally killed all of his libvirt-started
dnsmasq instances (due to a buggy dnsmasq service script in Fedora
16), and had hoped that libvirtd would notice this on restart and
reload all the dnsmasq daemons (as it does with iptables
rules). Unfortunately this was not the case - as long as the network
object had a pid registered for dnsmasq and/or radvd, it assumed that
the processes were running.

This patch takes advantage of the new utility functions in
bridge_driver.c to do a "refresh" of all radvd and dnsmasq processes
started by libvirt each time libvirtd is restarted - this function
attempts to do a SIGHUP of each existing process, and if that fails,
it restarts the process, rebuilding all the associated config files
and commandline parameters in the process. This normally has no
effect, but will be useful in solving the occasional "odd situation"
without needing to take the drastic step of destroying/re-starting the
network.

network: implement virNetworkUpdate for test_driver

The test driver does nothing outside of keeping track of each
network's config/state in the in-memory database maintained by
network_conf functions, so all we have to do is call the function that
updates the network's entry in the in-memory database.

network: implement virNetworkUpdate for bridge_driver

Call the network_conf function that modifies the live/persistent/both
config, then refresh/restart dnsmasq/radvd if necessary, and finally
save the config in the proper place(s).

This patch also needed to uncomment a few utility functions that were
added inside #if 0 in the previous commit (to avoid compiler errors
due to unreferenced static functions).

network: reorganize dnsmasq and radvd config file / startup

This patch splits the starting of dnsmasq and radvd into multiple
files, and adds new networkRefreshXX() and networkRestartXX()
functions for each. These new functions are currently commented out
because they won't be used until the next commit, and the compile options
require all static functions to be used.

networkRefreshXX() - rewrites any file-based config for dnsmasq/radvd,
and sends SIGHUP to the process to make it reread its config. If the
program isn't already running, it's just started.

networkRestartXX() - kills the given program, waits for it to exit
(see the comments in the function networkKillDaemon()), then calls
networkStartXX().

This commit is here mostly as a checkpoint to verify no change in
functional behavior after refactoring networkStartXX() functions to
fit in with these new functions.

conf: implement NetworkObj backend of virNetworkUpdate API

virNetworkObjUpdate takes care of all virNetworkUpdate-related changes
to the data stored in the in-memory virNetworkObj list. It should be
called by network drivers that use this in-memory list.

virNetworkObjUpdate *does not* take care of updating any disk-based
copies of the config, nor does it perform any other operations
necessary to have the new config data take effect (e.g. it won't
re-write dnsmasq host files, nor will it send a SIGHUP to dnsmasq) -
those things should all be taken care of in the network driver
function that calls virNetworkObjUpdate (assuming that it returns
success).

network: utility functions for updating network config

These new functions are highly inspired by those in domain_conf.c (but
not identical), and are intended to make it simpler to update the
various combinations of live/persistent network configs.

The network driver wasn't previously as careful about the separation
between the live "status" in network->def and the persistent "config"
in network->newDef (or sometimes in network->def). This series
attempts to remedy some of that, but probably doesn't go all the way
(enough to get these functions working and enable continued work on
virNetworkUpdate though).

bridge_driver.c and test_driver.c were updated in a few places to take
advantage of the new functions and/or account for changes in argument
lists.

network: implement RPC calls for virNetworkUpdate

This is very short, because almost everything is autogenerated. All
that's needed are:

* src/remote/remote_driver.c: add pointer to autogenerated
    remoteNetworkUpdate to the function table for the remote
    network driver.

* src/remote/remote_protocol.x: add the "args" struct and add one more
    item to the remote_procedure enum for this function.

* src/remote_protocol-struct: update to match remote_protocol.x

network: define new API virNetworkUpdate

This patch adds a new public API virNetworkUpdate that will permit
updating an existing network configuration without requiring that the
network be destroyed/restarted for the changes to take effect.

tests: add qemu-1.2.0 help data

Generated with:

qemu-system-x86_64 -help >tests/qemuhelpdata/qemu-1.2.0
qemu-system-x86_64 \
    -device ? \
    -device pci-assign,? \
    -device virtio-blk-pci,? \
    -device virtio-net-pci,? \
    -device scsi-disk,? 2>tests/qemuhelpdata/qemu-1.2.0-device

qemu: add -sandbox to command line if requested

qemu: conf: add seccomp_sandbox option

qemu: add capability flag for seccomp sandbox

This series adds support to run QEMU with seccomp sandbox enabled. It can be
configured in qemu.conf to on, off, or the QEMU default, which is off in 1.2.
Default value is the QEMU default.

qemu: Avoid deadlock on HandleAgentEOF

On agent EOF the qemuProcessHandleAgentEOF() callback is called
which locks virDomainObjPtr. Then qemuAgentClose() is called
(with domain object locked) which eventually calls qemuAgentDispose()
and qemuProcessHandleAgentDestroy(). This tries to lock the
domain object again. Hence the deadlock.

qemu: Use disk wwn in qemu command line

All of ide-drive, ide-hd, ide-cd, scsi-disk, scsi-hd, and scsi-cd
supports wwn property. (NB, scsi-block doesn't support to set wwn).

* src/qemu/qemu_command.c: Error out if underlying QEMU doesn't
support wwn property for the device; Set wwn for the device otherwise.

* tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args: New test
* tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.xml: Likewise
* tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args: Likewise
* tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml: Likewise
* tests/qemuxml2argvtest.c: Add the new tests.

qemu: Add caps to indentify if setting wwn is supported by qemu

This assumes ide-drive.wwn, ide-hd.wwn, ide-cd.wwn were supported
at the same time, similar for scsi-disk.wwn, scsi-hd.wwn, and
scsi-cd.wwn. So only two new caps (QEMU_CAPS_IDE_DRIVE_WWN,
and QEMU_CAPS_SCSI_DISK_WWN) are introduced.

conf: Parse and format disk <wwn>

Validates the wwn while parsing, error out if it's malformed.

* src/util/util.h: Declare virValidateWWN
* src/util/util.c: Implement virValidateWWN
* src/libvirt_private.syms: Export virValidateWWN.
* src/conf/domain_conf.h: New member 'wwn' for disk def.
* src/conf/domain_conf.c: Parse and format disk <wwn>

schema: Add schema for disk <wwn>

* docs/formatdomain.html.in: Add document.
* docs/schemas/nodedev.rng: Move definition of "wwn" to ...
* docs/schemas/basictypes.rng: ...Here
* docs/schemas/domaincommon.rng: Add schema for disk <wwn>

blockjob: add blockcommit support to rpc

Relatively straightforward.  Our decision to make block job
speed a long keeps haunting us on new API.

* src/remote/remote_protocol.x (remote_domain_block_commit_args):
New struct.
* src/remote/remote_driver.c (remote_driver): Enable it.
* src/remote_protocol-structs: Regenerate.
* src/rpc/gendispatch.pl (long_legacy): Exempt another bandwidth.

blockjob: add virsh blockcommit

The new command 'virsh blockcommit $dom $disk' requests the start
of an asynchronous commit operation across the entire chain of
$disk.  Further arguments can fine-tune which portion of the
chain is committed.  Existing 'virsh blockjob' commands can then
track the status, change the bandwidth, or abort the commit job.

With a bit more on the command line, 'virsh blockcommit $dom $disk
--wait --verbose' can be used for blocking behavior, with visual
feedback on the overall status, and can be canceled with Ctrl-C.

The overall design, including the wait loop logic, borrows heavily
from the existing blockpull command.

* tools/virsh-domain.c (cmdBlockCommit): New function.
* tools/virsh.pod (blockcommit): Document it.

blockjob: add virDomainBlockCommit

A block commit moves data in the opposite direction of block pull.
Block pull reduces the chain length by dropping backing files after
data has been pulled into the top overlay, and is always safe; block
commit reduces the chain length by dropping overlays after data has
been committed into the backing file, and any files that depended
on base but not on top are invalidated at any point where they have
unallocated data that is now pointing to changed contents in base.
Both directions are useful, however: a qcow2 layer that is more than
50% allocated will typically be faster with a pull operation, while
a qcow2 layer with less than 50% allocation will be faster as a
commit operation.  Committing across multiple layers can be more
efficient than repeatedly committing one layer at a time, but
requires extra support from the hypervisor.

This API matches Jeff Cody's proposed qemu command 'block-commit':
https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02226.html

Jeff's command is still in the works for qemu 1.3, and may gain
further enhancements, such as the ability to control on-error
handling (it will be comparable to the error handling Paolo is
adding to 'drive-mirror', so a similar solution will be needed
when I finally propose virDomainBlockCopy with more functionality
than the basics supported by virDomainBlockRebase).  However, even
without qemu support, this API will be useful for _offline_ block
commits, by wrapping qemu-img calls and turning them into a block
job, so this API is worth committing now.

For some examples of how this will be implemented, all starting
with the chain: base <- snap1 <- snap2 <- active

+ These are equivalent:
 virDomainBlockCommit(dom, disk, NULL, NULL, 0, 0)
 virDomainBlockCommit(dom, disk, NULL, "active", 0, 0)
 virDomainBlockCommit(dom, disk, "base", NULL, 0, 0)
 virDomainBlockCommit(dom, disk, "base", "active", 0, 0)
but cannot be implemented for online qemu with round 1 of
Jeff's patches; and for offline images, it would require
three back-to-back qemu-img invocations unless qemu-img
is patched to allow more efficient multi-layer commits;
the end result would be 'base' as the active disk with
contents from all three other files, where 'snap1' and
'snap2' are invalid right away, and 'active' is invalid
once any further changes to 'base' are made.

+ These are equivalent:
 virDomainBlockCommit(dom, disk, "snap2", NULL, 0, 0)
 virDomainBlockCommit(dom, disk, NULL, NULL, 0, _SHALLOW)
they cannot be implemented for online qemu, but for offline,
it is a matter of 'qemu-img commit active', so that 'snap2'
is now the active disk with contents formerly in 'active'.

+ Similarly:
 virDomainBlockCommit(dom, disk, "snap2", NULL, 0, _DELETE)
for an offline domain will merge 'active' into 'snap2', then
delete 'active' to avoid leaving a potentially invalid file
around.

+ This version:
 virDomainBlockCommit(dom, disk, NULL, "snap2", 0, _SHALLOW)
can be implemented online with 'block-commit' passing a base of
snap1 and a top of snap2; and can be implemented offline by
'qemu-img commit snap2' followed by 'qemu-img rebase -u
-b snap1 active'

* include/libvirt/libvirt.h.in (virDomainBlockCommit): New API.
* src/libvirt.c (virDomainBlockCommit): Implement it.
* src/libvirt_public.syms (LIBVIRT_0.10.2): Export it.
* src/driver.h (virDrvDomainBlockCommit): New driver callback.
* docs/apibuild.py (CParser.parseSignature): Add exception.

qemu: drop unused arguments for dump-guest-memory

Upstream qemu has raised a concern about whether dumping guest
memory by reading guest paging tables is a security hole:
https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02607.html

While auditing libvirt to see if we would be impacted, I noticed
that we had some dead code.  It is simpler to nuke the dead code
and limit our monitor code to just the subset we make use of.

* src/qemu/qemu_monitor.h (QEMU_MONITOR_DUMP): Drop poorly named
and mostly-unused enum.
* src/qemu/qemu_monitor.c (qemuMonitorDumpToFd): Drop arguments.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONDump): Likewise.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONDump): Likewise.
* src/qemu/qemu_driver.c (qemuDumpToFd): Update caller.

build: Fix build failure on non-linux platform

conf: avoid freeing network object with undestroyed mutex

virNetworkAssignDef was allocating a new network object, initing and
grabbing its lock, then potentially freeing it without unlocking or
destroying the lock. In practice 1) this will probably never happen,
and 2) even if it did, the lock implementation used on most (all?)
platforms doesn't actually hold any resources for an initialized or
held lock, but it still bothered me, so I moved the realloc that could
lead to this bad situation earlier in the function, and now the mutex
isn't inited or locked until we are assured of complete success.

conf: separate functions to parse DHCPHostDef and DHCPRangeDef

These two objects were previously always parsed as a part of an IpDef,
but we will now need to be able to parse them on their own for
virNetworkUpdate(). Split the parsing functions out, with no
functional changes.

remove virDomainCpuSetFormat and virDomainCpuSetParse

virBitmap is recommanded to store cpuset info, and
virBitmapFormat/virBitmapParse can do the format/parse
jobs.

xen: eliminate remaining uses of virDomainCpuSetParse

The final patch in Hu Tao's series to enhance virBitmap actually
removes virDomainCpuSetParse and virDomainCpuSetFormat as "no longer
used", and the rest of the series hadn't taken care of two uses of
virDomainCpuSetParse in the xen code.

This patch replaces those with appropriate virBitmap functions. It
should be pushed prior to the patch removing virDomainCpuSetParse.

use virBitmap to store nodeinfo.

use virBitmap to store cells' cpumask info.

use virBitmap to store cpumask info.

use virBitmap to store numa nodemask info.

use virBitmap to store cpu affinity info

use virBitmap to store cpupin info

New functions for virBitmap

In many places we store bitmap info in a chunk of data
(pointed to by a char *), and have redundant codes to
set/unset bits. This patch extends virBitmap, and convert
those codes to use virBitmap in subsequent patches.

bitmap: new member variable and function renaming

Add a new member variable map_len to store map len of bitmap.
and rename size to max_bit accordingly.

rename virBitmapAlloc to virBitmapNew.

virsh: Clarify behavior of domain list filtering.

Some combinations of filtering flags produce no result. This patch tries
to clarify this.

Build: Fix typos which cause build failure

Pushed under build-breaker rules.

node_memory: Expose the APIs to Python bindings

* python/libvirt-override-api.xml: (Add document to describe
  the APIs).
* python/libvirt-override.c: (Implement the API wrappers manually)

node_memory: Expose the APIs to virsh

New command node-memory-tune to get/set the node memory parameters,
only two parameters are allowed to set (pages_to_scan, and sleep_millisecs,
see documents in this patch for more details).

Example of node-memory-tune's output:

Shared memory:
pages_to_scan   100
sleep_millisecs 20
pages_shared    0
pages_sharing   0
pages_unshared  0
pages_volatile  0
full_scans      0

node_memory: Support get/set memory parameters for drivers

Including QEMU, LXC, UML, XEN drivers.

node_memory: Implement the internal APIs

Only implemented for linux platform.

* src/nodeinfo.h: (Declare node{Get,Set}MemoryParameters)
* src/nodeinfo.c: (Implement node{Get,Set}MemoryParameters)
* src/libvirt_private.syms: (Export those two new internal APIs to
  private symbols)

node_memory: Wire up the RPC protocol

* src/rpc/gendispatch.pl: (virNodeSetMemoryParameters is the
  the special one which needs a connection object as the first
  argument, improve the generator to support it).
* daemon/remote.c: (Implement the server side handler for
  virDomainGetMemoryParameters)
* src/remote/remote_driver.c: (Implement the client side handler
  for virDomainGetMemoryParameters)
* src/remote/remote_protocol.x: (New RPC procedures for the two
  new APIs and structs to represent the args and ret for it)
* src/remote_protocol-structs: Likewise

node_memory: Define the APIs to get/set memory parameters

* include/libvirt/libvirt.h.in: (Add macros for the param fields,
  declare the APIs).
* src/driver.h: (New methods for the driver struct)
* src/libvirt.c: (Implement the public APIs)
* src/libvirt_public.syms: (Export the public symbols)

list: Use virConnectListAllSecrets in virsh

This introduces four new options for secret-list, to filter the
returned secrets by whether it's ephemeral or not, and/or by
whether it's private or not.

* tools/virsh-secret.c: (New helper vshSecretSorter,
  vshSecretListFree, and vshCollectSecretList; Use the new
  API for secret-list; error out if flags are specified,
  because there is no way to filter the results when using
  old APIs (no APIs to get the properties (ephemeral, private)
  of a secret yet).

* tools/virsh.pod: Document the 4 new options.

list: Expose virConnectListAllSecrets to Python binding

The implementation is done manually as the generator does not support
wrapping lists of C pointers into Python objects.

python/libvirt-override-api.xml: Document

python/libvirt-override-virConnect.py: Implementation for listAllSecrets.

python/libvirt-override.c: Implementation for the wrapper.

list: Implement listAllSecrets

Simply returns the object list. Supports to filter the secrets
by its storage location, and whether it's private or not.

src/secret/secret_driver.c: Implement listAllSecrets

list: Implement RPC calls for virConnectListAllSecrets

The RPC generator doesn't support returning list of object yet, this patch
does the work manually.

  * daemon/remote.c:
    Implement the server side handler remoteDispatchConnectListAllSecrets.

  * src/remote/remote_driver.c:
    Add remote driver handler remoteConnectListAllSecrets.

  * src/remote/remote_protocol.x:
    New RPC procedure REMOTE_PROC_CONNECT_LIST_ALL_SECRETS and
    structs to represent the args and ret for it.

  * src/remote_protocol-structs: Likewise.

list: Define new API virConnectListAllSecrets

This is to list the secret objects. Supports to filter the secrets
by its storage location, and whether it's private or not.

include/libvirt/libvirt.h.in: Declare enum virConnectListAllSecretFlags
                              and virConnectListAllSecrets.
python/generator.py: Skip auto-generating
src/driver.h: (virDrvConnectListAllSecrets)
src/libvirt.c: Implement the public API
src/libvirt_public.syms: Export the symbol to public

list: Use virConnectListAllNWFilters in virsh

tools/virsh-nwfilter.c:
  * vshNWFilterSorter to sort network filters by name

  * vshNWFilterListFree to free the network filter objects list.

  * vshNWFilterListCollect to collect the network filter objects, trying
    to use new API first, fall back to older APIs if it's not supported.

list: Expose virConnectListAllNWFilters to Python binding

The implementation is done manually as the generator does not support
wrapping lists of C pointers into Python objects.

python/libvirt-override-api.xml: Document

python/libvirt-override-virConnect.py:
  * Implementation for listAllNWFilters.

python/libvirt-override.c: Implementation for the wrapper.

list: Implement listAllNWFilters

Simply returns the object list. No filtering.

src/nwfilter/nwfilter_driver.c: Implement listAllNWFilters

list: Implement RPC calls for virConnectListAllNWFilters

The RPC generator doesn't support returning list of object yet, this patch
do the work manually.

  * daemon/remote.c:
    Implemente the server side handler remoteDispatchConnectListAllNWFilters.

  * src/remote/remote_driver.c:
    Add remote driver handler remoteConnectListAllNWFilters.

  * src/remote/remote_protocol.x:
    New RPC procedure REMOTE_PROC_CONNECT_LIST_ALL_NWFILTERS and
    structs to represent the args and ret for it.

  * src/remote_protocol-structs: Likewise.

list: Define new API virConnectListAllNWFilters

This is to list the network filter objects. No flags are supported

include/libvirt/libvirt.h.in: Declare enum virConnectListAllNWFilterFlags
                              and virConnectListAllNWFilters.
python/generator.py: Skip auto-generating
src/driver.h: (virDrvConnectListAllNWFilters)
src/libvirt.c: Implement the public API
src/libvirt_public.syms: Export the symbol to public

list: Use virConnectListAllNodeDevices in virsh

tools/virsh-nodedev.c:
  * vshNodeDeviceSorter to sort node devices by name

  * vshNodeDeviceListFree to free the node device objects list.

  * vshNodeDeviceListCollect to collect the node device objects, trying
    to use new API first, fall back to older APIs if it's not supported.

  * Change option --cap to accept multiple capability types.

tools/virsh.pod
  * Update document for --cap

virsh: Don't motify the const string

This improve helper vshStringToArray to accept const string as
argument instead. To not convert the const string when using
vshStringToArray, and thus avoid motifying it.

list: Expose virConnectListAllNodeDevices to Python binding

The implementation is done manually as the generator does not support
wrapping lists of C pointers into Python objects.

python/libvirt-override-api.xml: Document

python/libvirt-override-virConnect.py:
  * Implementation for listAllNodeDevices.

python/libvirt-override.c: Implementation for the wrapper.

list: Implement listAllNodeDevices

This simply implements listAllNodeDevices using helper virNodeDeviceList

src/node_device/node_device_driver.h:
  * Declare nodeListAllNodeDevices.

src/node_device/node_device_driver.c:
  * Implement nodeListAllNodeDevices.

src/node_device/node_device_hal.c:
  * Hook listAllNodeDevices to nodeListAllNodeDevices.

src/node_device/node_device_udev.c
  * Hook listAllNodeDevices to nodeListAllNodeDevices.

list: Add helpers for listing node devices

src/conf/node_device_conf.h:
  * New macro VIR_CONNECT_LIST_NODE_DEVICES_FILTERS_CAP
  * Declare virNodeDeviceList

src/conf/node_device_conf.c:
  * New helpers virNodeDeviceCapMatch, virNodeDeviceMatch.
    virNodeDeviceCapMatch looks up the list of all the caps the device
    support, to see if the device support the cap type.
  * Implement virNodeDeviceList

src/libvirt_private.syms:
  * Export virNodeDeviceList
  * Export virNodeDevCapTypeFromString

list: Implement RPC calls for virConnectListAllNodeDevices

The RPC generator doesn't support returning list of object yet, this patch
does the work manually.

  * daemon/remote.c:
    Implemente the server side handler remoteDispatchConnectListAllNodeDevices.

  * src/remote/remote_driver.c:
    Add remote driver handler remoteConnectListAllNodeDevices.

  * src/remote/remote_protocol.x:
    New RPC procedure REMOTE_PROC_CONNECT_LIST_ALL_INTERFACES and

list: Define new API virConnectListAllNodeDevices

This is to list the node device objects, supports to filter the results
by capability types.

include/libvirt/libvirt.h.in: Declare enum virConnectListAllNodeDeviceFlags
                              and virConnectListAllNodeDevices.
python/generator.py: Skip auto-generating
src/driver.h: (virDrvConnectListAllNodeDevices)
src/libvirt.c: Implement the public API
src/libvirt_public.syms: Export the symbol to public

build: fix missing include

virNWFilterSnoopAdjustPoll() uses a struct pollfd but poll.h is never included
nwfilter/nwfilter_dhcpsnoop.c:1297: error: 'struct pollfd' declared inside parameter list

Add missing 'goto error' in QEMU command line building

If reporting case of a binary not supporting KVM or kQEMU, libvirt
forgot to jump to the error branch for cleanup

Fix initialization of virCommandPtr when creating QEMU argv

If the qemuBuildCommandLine method raised an error before the
virCommandPtr instance was created, the local var would not
be initialized, resulting in a possible SEGV in the error
cleanup branch. Also add some debugging of the method params

Fix 3 broken test cases which were mistakenly raising errors

Several test cases were mistakenly raising errors due to the
QEMU_CAPS_KVM flag being missed.

qemu: fix uninitialized variable in qemuParseCommandLine

Newly added if branch for kvm_pv_eoi did not set the ret variable.

Introduce a API for creating QEMU capabilities for a binary

Introduce a qemuCapsNewForBinary() API which creates a new
QEMU capabilities object, populated with data relating to
a specific QEMU binary. The qemuCaps object is also given
a timestamp, which makes it possible to detect when the
cached capabilities for a binary are out of date

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Remove upfront check for hmp - just try it cope with failure

Don't bother checking for the existance of the HMP passthrough
command. Just try to execute it, and propagate the failure.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Don't overwrite errors raised by qemuMonitorHMPCommand

The qemuMonitorHMPCommand() API and things it calls will report
a wide variety of errors. The QEMU text monitor should not be
overwriting these errors

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

qemu: Add support for EOI with APIC

This patch adds full support for EOI setting for domains. Because this
is CPU feature (flag), the model needs to be added even when it's not
specified. Fortunately this problem was already solved with kvmclock,
so this patch simply abuses that.

And due to the size of the patch (17 lines) I dared to include the tests.

Add support for EOI with APIC

New options is added to support EOI (End of Interrupt) exposure for
guests. As it makes sense only when APIC is enabled, I added this into
the <apic> element in <features> because this should be tri-state
option (cannot be handled as standalone feature).

security: Fix libvirtd crash possibility

Fix for CVE-2012-4423.

When generating RPC protocol messages, it's strictly needed to have a
continuous line of numbers or RPC messages. However in case anyone
tries backporting some functionality and will skip a number, there is
a possibility to make the daemon segfault with newer virsh (version of
the library, rpc call, etc.) even unintentionally.

The problem is that the skipped numbers will get func filled with
NULLs, but there is no check whether these are set before the daemon
tries to run them. This patch very simply enhances one check and fixes
that.

snapshot: fix rollback failure in transaction mode

BZ:https://bugzilla.redhat.com/show_bug.cgi?id=843372
when qemu supports the 'transaction' monitor command,
and libvirt's --reuse-ext flag was not specified, libvirt created
a stub file with zero size in first place. After the failure of
QEMU transaction command performing qcow2 snapshots on more than
one drives, the stub file is left behind with non-empty
by the QEMU transaction command.
In order to unlink the file, the patch removes the file size checking.

Steps to reproduce the issue:
Steps:
 1, Create a qemu instance with two drive images of qcow2 type (root user)
    /usr/libexec/qemu-kvm -m 1024 -smp 1 -name "rhel6u1" \
      -drive file=/var/lib/libvirt/images/firstqcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
      -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
      -drive file=/var/lib/libvirt/images/secondqcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none \
      -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -qmp stdio

 2, Initialize qemu qmp
    {"execute":"qmp_capabilities"}

 3, Remove the second drive image file
    rm -f /var/lib/libvirt/images/secondqcow2

 4, Run 'transaction' command with snapshot qemu commands in.
    {"execute":"transaction","arguments":
      {"actions":
        [{"type":"blockdev-snapshot-sync","data":
          {"device":"drive-virtio-disk0","snapshot-file":"/var/lib/libvirt/images/firstqcow2-snapshot.img","format":"qcow2"}
         },
         {"type":"blockdev-snapshot-sync","data":
          {"device":"drive-virtio-disk1","snapshot-file":"/var/lib/libvirt/images/secondqcow2-snapshot.img","format":"qcow2"}
         }]
      },
   "id":"libvirt-6"}

 5, Got the error as follows:
    {"id": "libvirt-6",
      "error": {"class": "OpenFileFailed", "desc": "Could not open '/var/lib/libvirt/images/secondqcow2-snapshot.img'",
                "data": {"filename": "/var/lib/libvirt/images/secondqcow2-snapshot.img"}
               }
    }

 6, List first newly-created snapshot file:
    -rw-r--r--. 1 root root     262144 Sep 13 11:43 firstqcow2-snapshot.img

Improve virTypedParameterValidateSet

Assume not only domain object will use it.

Look in Debian's multiarch libs too

so we don't fail when libnetcf is built as multiarch lib.

build: don't fail if libnl-3 is not found

Commit 9298bfb changed configure to split the libnl into two
separate pkg config checks instead of nesting the second check
on the failure path of the first.  But the default pkg config
behavior is to abort configure if a check fails.  Since we have
a second check lined up, we need an explicit failure case that
does not abort if the first check fails.

Meanwhile, commit 51b708c is reverted.  It did not fix any
behavior, and in fact, introduced a regression to the fallback
case when the user explicitly sets $LIBNL_CFLAGS.

* configure.ac: Don't abort if libnl-3 is not found.

conf: avoid libvirt crash with empty address guestfwd channel

The 'def->target.addr' hasn't been initialized in virDomainChrDefNew() and
its value is always '0xffffffff', in addition, the following test scenario
hasn't also include 'address' element in channel XML block, so the branch
'if (addrStr == NULL)' is hit in virDomainChrDefParseTargetXML(), the
programming jumps to 'error' label to release relevant resources, and the
statement 'if (VIR_ALLOC(def->target.addr) < 0)' hasn't been executed then
the virDomainChrDefFree() will free 'def->target.addr'(0xffffffff) via
VIR_FREE(), which results in libvirt crash, to use valgrind can also
find a 'Invalid free() / delete / delete[]' error. This patch just adjusts
codes order to initialize 'def->target.addr' firstly.

With this patch, libvirt hasn't crash and can get a expected error message "
XML error: guestfwd channel does not define a target address".

How to reproduce?

1. define a guest with the following channel XML configuration

$ cat foo.xml
<snip>
    <channel type='pty'>
      <target type='guestfwd'/>
    </channel>
</snip>

$ virsh define foo.xml

2. actual result

error: Failed to define domain from /tmp/foo.xml
error: End of file while reading data: Input/output error
error: Failed to reconnect to the hypervisor

GDB debugger information:
<snip>
Breakpoint 1, virDomainChrDefFree (def=0x7f8ab000ec70) at conf/domain_conf.c:1264
...ignore
1264    {
(gdb) p def->target
$2 = {port = -1, addr = 0xffffffff, name = 0xffffffff <Address 0xffffffff out of bounds>}
</snip>

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

Signed-off-by: Alex Jia <ajia@redhat.com>

parallels: implement containers creation

Add separate function parallelsCreateCt, which creates container.
Also add example xml configuration domain-parallels-ct-simple.xml.

Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

parallels: fix parallelsDomainDefineXML for existing containers

Fix code, which checks what is changed in virDomainDef structure.
It looks slightly different for containers and VMs: containers haven't
boot devices, but have init path

Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

parallels: handle unlimited cpus on containers

User may set "unlimited" cpus for containers, which means to
take all available cpus on the node.

Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

parallels: add support of containers to the driver

This patch makes parallelsLoadDomains to be able to load information
about containers. So functions, which return different information
and change state will work.

parallelsDomainDefineXML will be fixed in separate patch.

Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

Fix data types used for list sizes in QEMU capabilities

The QEMU capabilities APIs used a misc of 'int' and
'unsigned int' for variables relating to array sizes.
Change all these to use 'size_t'

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Add API for copying instances of the qemuCapsPtr object

To allow each VM instance to record additional capabilities
without affecting other VMs, there needs to be a way to do
a deep copy of the qemuCapsPtr object

Add ability to store other metadata in the qemu capabilities object

Add struct fields and APIs to allow the qemu capabilities object
to store version, arch, machines & cpu names, etc

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Make qemuCapsProbeCommand static

The qemuCapsProbeCommand API is only used by the capabilities
code, so can be static

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Turn QEMU capabilities object into a full virObjectPtr

The current qemu capabilities are stored in a virBitmapPtr
object, whose type is exposed to callers. We want to store
more data besides just the flags, so we need to move to a
struct type. This object will also need to be reference
counted, since we'll be maintaining a cache of data per
binary. This change introduces a 'qemuCapsPtr' virObject
class. Most of the change is just renaming types and
variables in all the callers

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Allow caps to be NULL when creating virDomainObjPtr instances

If no private data needs to be maintained, it can be useful
to create virDomainObjPtr instances without having a virCapsPtr
instance around. Adapt the virDomainObjNew() function to allow
for a NULL caps

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Wait to receive QMP greeting before sending any monitor commands

Technically speaking we should wait until we receive the QMP
greeting message before attempting to send any QMP monitor
commands. Mostly we've got away with this, but there is a race
in some QEMU which cause it to SEGV if you sent it data too
soon after startup. Waiting for the QMP greeting avoids the
race

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>