At one point, the code passed through arbitrary strings for file
formats, which supposedly lets qemu handle a new file type even
before libvirt has been taught to handle it.  However, to properly
label files, libvirt has to learn the file type anyway, so we
might as well make our life easier by only accepting file types
that we are prepared to handle.  This patch lets the RNG validation
ensure that only known strings are let through.

* docs/schemas/domaincommon.rng (driverFormat): Limit to list of
supported strings.
* docs/schemas/domainsnapshot.rng (driver): Likewise.

Hypervisors are starting to support HyperV Enlightenment features that
improve behavior of guests running Microsoft Windows operating systems.

This patch adds support for the "relaxed" feature that improves timer
behavior and also establishes a framework to add these features in
future.

Given Daniel's announcement[1], code targetting the next release will
be in 1.0.0, not 0.10.3.  Changed mechanically with:

for f in $(git grep -l '0\(.\)10\13\b') ; do
   sed -i -e 's/0\(.\)10\13/1\10\10/g' $f
done

[1]https://www.redhat.com/archives/libvir-list/2012-October/msg00403.html

* docs/formatdomain.html.in: Use 1.0.0 for next release.
* src/interface/interface_backend_udev.c: Likewise.

These 3 elements conflicts with each other in either the doc
or the underlying codes.

Current problems:

Problem 1:

The doc shouldn't simply say "These settings are superseded
by CPU tuning. " for element <vcpu>. As except the tuning, <vcpu>
allows to specify the current, maxmum vcpu number. Apart from that,
<vcpu> also allows to specify the placement as "auto", which binds
the domain process to the advisory nodeset from numad.

Problem 2:

Doc for <vcpu> says its "cpuset" specify the physical CPUs
that the vcpus can be pinned. But it's not the truth, as
actually it only pin domain process to the specified physical
CPUs. So either it's a document bug, or code bug.

Problem 3:

Doc for <vcpupin> says it supersed "cpuset" of <vcpu>, it's
not quite correct, as each <vcpupin> specify the pinning policy
only for one vcpu. How about the ones which doesn't have
<vcpupin> specified? it says the vcpu will be pinned to all
available physical CPUs, but what's the meaning of attribute
"cpuset" of <vcpu> then?

Problem 4:

Doc for <emulatorpin> says it pin the emulator threads (domain
process in other context, perhaps another follow up patch to
cleanup the inconsistency is needed) to the physical CPUs
specified its attribute "cpuset". Which conflicts with
<vcpu>'s "cpuset". And actually in the underlying codes,
it set the affinity for domain process twice if both
"cpuset" for <vcpu> and <emulatorpin> are specified,
and <emulatorpin>'s pinning will override <vcpu>'s.

Problem 5:

When "placement" of <vcpu> is "auto" (I.e. uses numad to
get the advisory nodeset to which the domain process is
pinned to), it will also be overridden by <emulatorpin>,

This patch is trying to sort out the conflicts or bugs by:

1) Don't say <vcpu> is superseded by <cputune>

2) Keep the semanteme for "cpuset" of <vcpu> (I.e. Still says it
   specify the physical CPUs the virtual CPUs). But modifying it
   to mention it also set the pinning policy for domain process,
   and the CPU placement of domain process specified by "cpuset"
   of <vcpu> will be ingored if <emulatorpin> specified, and
   similary, the CPU placement of vcpu thread will be ignored
   if it has <vcpupin> specified, for vcpu which doesn't have
   <vcpupin> specified, it inherits "cpuset" of <vcpu>.

3) Don't say <vcpu> is supersed by <vcpupin>. If neither <vcpupin>
   nor "cpuset" of <vcpu> is specified, the vcpu will be pinned
   to all available pCPUs.

4) If neither <emulatorpin> nor "cpuset" of <vcpu> is specified,
   the domain process (emulator threads in the context) will be
   pinned to all available pCPUs.

5) If "placement" of <vcpu> is "auto", <emulatorpin> is not allowed.

6) hotplugged vcpus will also inherit "cpuset" of <vcpu>

Codes changes according to above document changes:

1) Inherit def->cpumask for each vcpu which doesn't have <vcpupin>
   specified, during parsing.

2) ping the vcpu which doesn't have <vcpupin> specified to def->cpumask
   either by cgroup for sched_setaffinity(2), which is actually done
   by 1).

3) Error out if "placement" == "auto", and <emulatorpin> is specified.
   Otherwise, <emulatorpin> is honored, and "cpuset" of <cpuset> is
   ignored.

4) Setup cgroup for each hotplugged vcpu, and setup the pinning policy
   by either cgroup or sched_setaffinity(2).

5) Remove cgroup and <vcpupin> for each hot unplugged vcpu.

Patches are following (6 in total except this patch)

When startupPolicy set for a USB devices allows such device to be
missing, there was no way this could be detected from domain XML. With
this patch, libvirt emits a new missing='yes' attribute for such devices
when active domain XML is generated.

USB devices can disappear without OS being mad about it, which makes
them ideal for startupPolicy. With this attribute, USB devices can be
configured to be mandatory (the default), requisite (will disappear
during migration if they cannot be found), or completely optional.

While the changes to sanlock driver should be stable, the actual
implementation of sanlock_helper is supposed to be replaced in the
future. However, before we can implement a better sanlock_helper, we
need an administrative interface to libvirtd so that the helper can just
pass a "leases lost" event to the particular libvirt driver and
everything else will be taken care of internally. This approach will
also allow libvirt to pass such event to applications and use
appropriate reasons when changing domain states.

The temporary implementation handles all actions directly by calling
appropriate libvirt APIs (which among other things means that it needs
to know the credentials required to connect to libvirtd).

This is required in case a lock manager needs to contact libvirtd in
case of an unexpected event.

Using this new element, one can configure an action that should be
performed when resource locks are lost.

While current on_{poweroff,reboot,crash} action configuration is about
configuring life cycle actions, they can all be considered events and
actions that need to be done on a particular event. Let's generalize the
code by renaming life cycle actions to event actions so that it can be
reused later for non-lifecycle events.

Use of the wrong attribute name caused the table of contents to
be useless.  Fix suggested by Daniel P. Berrange.

* docs/migration.html.in: Use correct anchoring attribute.

Getting a artifact into Maven central has a lot of restrictions as
where the artifact should be hosted.

This seemed like a big hassle which we don't want to go through now.

Document a way for users to use libvirt.org as a repository so they can
fetch the Java bindings with maven.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

Based on a report that phyp is undocumented:
https://www.redhat.com/archives/libvirt-users/2012-July/msg00013.html

* docs/drvphyp.html.in (phyp): New file.
* docs/drivers.html.in: List it.

This patch adds a brief description about labels for each security
driver.

--enable-compile-warnings=error has been renamed to --enable-werror so
update the HACKING and the hacking.html to reflect that.

* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: update from transifex and regenerate

This allows the user to control labelling of each character device
separately (the default is to inherit from the VM).
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Noticed this by reading the page.  It would be so much nicer if our
tools could automatically flag things like this as part of 'make'.

* docs/formatdomain.html.in: Remove extra '>'.

This patch adds to relatedlinks.html a link to an article about libvirt
describing how the Linux audit subsystem can be used to track qemu
guest's life-cycle.

Sometimes when guest machine crashes, coredump can get huge due to the
guest memory. This can be limited using madvise(2) system call and is
being used in QEMU hypervisor. This patch adds an option for configuring
that in the domain XML and related documentation.

Whenever the guest machine fails to boot, new parameter (reboot-timeout)
controls whether it should reboot and after how many ms it should do so.

Docs included.

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).

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

* 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>

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.

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).

Reported on the libvirt-users list.

* docs/apps.html.in: Add Eucalyptus.
Reported by Eric Choi.

Links to the FAQ didn't work on pages in subdirectories, like
devhelp/libvirt-virterror.html or internals/command.html, because
they have had href_base prepended to them.

Two sections didn't have a working link in the TOC.

An email came to libvir-list wondering why the git send-email command
was missing in spite of having git installed; this is due to the
send-email command being in a sub-package of the main git package.

While touching the hacking file, I thought it would be useful to 1)
indicate the location of the source (docs/hacking.html.in) in the
message at the top of HACKING, and also to make the note about running
"make check" and "make syntax-check" a bit more stern.

On a machine without xsltproc, the build failed with:

Scripting search.php
/usr/local/bin/bash: line 1: search.php.tmp: No such file or directory
rm: ./search.php: No such file or directory

Regression introduced in commit 28183590.

* docs/Makefile.am (%.php): Skip in the same conditions when the
.tmp file is skipped.

After discussion with DB we decided to rename the new iolimit
element as it creates the impression it would be there to
limit (i.e. throttle) I/O instead of specifying immutable
characteristics of a block device.
This is also backed by the fact that the term I/O Limits has
vanished from newer storage admin documentation.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

There is a new <pm/> element implemented that can control what ACPI
sleeping states will be advertised by BIOS and allowed to be switched
to by libvirt. The default keeps defaults on hypervisor, otherwise
forces chosen setting.
The documentation of the pm element is added as well.

Introducing a new iolimits element allowing to override certain
properties of a guest block device like the physical and logical
block size.
This can be useful for platforms with 'non-standard' disk formats
like S390 DASD with its 4K block size.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

It should be [] instead of ().