Pretty easy to paste together compared to existing functions.

* src/esx/esx_driver.c (esxDomainSnapshotGetParent): New function.

When support for was added for PCI multifunction cards (in commit
9f8baf, first included in libvirt 0.9.3), it was done by always
turning on the multifunction bit for all PCI devices. Since that time
it has been realized that this is not an ideal solution, and that the
multifunction bit must be selectively turned on. For example, see

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

and the discussion before and after

  https://www.redhat.com/archives/libvir-list/2011-September/msg01036.html

This patch modifies multifunction support so that the multifunction=on
option is only added to the qemu commandline for a device if its PCI
<address> definition has the attribute "multifunction='on'", e.g.:

  <address type='pci' domain='0x0000' bus='0x00'
           slot='0x04' function='0x0' multifunction='on'/>

In practice, the multifunction bit should only be turned on if
function='0' AND other functions will be used in the same slot - it
usually isn't needed for functions 1-7 (although there are apparently
some exceptions, e.g. the Intel X53 according to the QEMU source
code), and should never be set if only function 0 will be used in the
slot. The test cases have been changed accordingly to illustrate.

With this patch in place, if a user attempts to assign multiple
functions in a slot without setting the multifunction bit for function
0, libvirt will issue an error when the domain is defined, and the
define operation will fail. In the future, we may decide to detect
this situation and automatically add multifunction=on to avoid the
error; even then it will still be useful to have a manual method of
turning on multifunction since, as stated above, there are some
devices that excpect it to be turned on for all functions in a slot.

A side effect of this patch is that attempts to use the same PCI
address for two different devices will now log an error (previously
this would cause the domain define operation to fail, but there would
be no log message generated). Because the function doing this log was
almost completely rewritten, I didn't think it worthwhile to make a
separate patch for that fix (the entire patch would immediately be
obsoleted).

While adding a new enum, I noticed a VIR_ENUM_DECL for a type that
doesn't exist. There is also of course no matching VIR_ENUM_IMPL for
it.

error:could not take a screenshot of xp
==6216== Syscall param unlink(pathname) points to unaddressable byte(s)
==6216==    at 0x373A0D4937: unlink (syscall-template.S:82)
==6216==    by 0x40FD73: cmdScreenshot (virsh.c:3070)
==6216==    by 0x42BA0D: vshCommandRun (virsh.c:14920)
==6216==    by 0x42EC97: main (virsh.c:16379)
==6216==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6216==
error:Requested operation is not valid: domain is not running

If the regexes supported (?:pvs)?, then we could handle this by
optionally matching but not returning the initial command name.  But it
doesn't.  So add a new char* argument to
virStorageBackendRunProgRegex().  If that argument is NULL then we act
as usual.  Otherwise, if the string at that argument is found at the
start of a returned line, we drop that before running the regex.

With this patch, virt-manager shows me lvs with command_names 1 or 0.

The definitions of PVS_BASE etc may want to be moved into the configure
scripts (though given how PVS is found, IIUC that could only happen if
pvs was a link to pvs_real), but in any case no sense dealing with that
until we're sure this is an ok way to handle it.
Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Currently, qemuDomainGetXMLDesc and qemudDomainGetInfo check for
outstanding synchronous job before (eventual) monitor entering.
However, there can be already async job set, e.g. migration.

Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>

Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>

Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>

Add new public api for 'reset'.
It can reset domain immediately without any guest shutdown.
Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>

Syslog puts the timestamp to every message anyway so this removes
redundant data.

Before, URIs such as hyperv+ssh:// have been declined by the Hyper-V
driver resulting in the remote driver trying to connect to an
non-existing libvirtd.

Now such URIs trigger an error in the yper-V driver suggesting to
try again without the transport part in the scheme.

Before, URIs such as esx+ssh:// have been declined by the ESX driver
resulting in the remote driver trying to connect to an non-existing
libvirtd.

Now such URIs trigger an error in the ESX driver suggesting to try
again without the transport part in the scheme.

there is no option "none":

>From libvirt/src/conf/domain_conf.c

<snip>
VIR_ENUM_IMPL(virDomainTimerTickpolicy,
VIR_DOMAIN_TIMER_TICKPOLICY_LAST,
              "delay",
              "catchup",
              "merge",
              "discard");
</snip>

Replacing with delay.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>

This patch is based on a improvement suggested by Kazuhiro Kikuchi
of Fujitsu, it gives a description of the target parameter for that
command

* tools/virsh.pod: add description for target parameter of
  attach-interface

The man page suggest that the cpu_shares parameter of schedinfo
allows values 0-262144, but the kernel remaps values 0 and 1 to
the minimum 2, just document that behaviour:

[root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares
1024
[root@test ~]# echo 0 > /cgroup/cpu/libvirt/qemu/cpu.shares
[root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares
2
[root@test ~]# echo 1 > /cgroup/cpu/libvirt/qemu/cpu.shares
[root@test ~]# cat /cgroup/cpu/libvirt/qemu/cpu.shares
2
[root@test ~]#

* tools/virsh.pod: update description of the cpu_shares parameter
  to indicate the values 0 and 1 are automatically changed by the
  kernel to minimal value 2

If the daemon is restarted so we reconnect to monitor, cdrom media
can be ejected. In that case we don't want to show it in domain xml,
or require it on migration destination.

To check for disk status use 'info block' monitor command.

* src/qemu/qemu_migration.c: if 'vmdef' is NULL, the function
  virDomainSaveConfig still dereferences it, it doesn't make
  sense, so should add return value check to make sure 'vmdef'
  is non-NULL before calling virDomainSaveConfig, in addition,
  in order to debug later, also should record error information
  into log.
Signed-off-by: NAlex Jia <ajia@redhat.com>

First hypervisor implementation of the new API.
Allows 'virsh snapshot-list --tree' to be more efficient.

* src/qemu/qemu_driver.c (qemuDomainSnapshotGetParent): New
function.

Reuse the tree listing of nodedev-list, coupled with the new helper
function to efficiently grab snapshot parent names, to produce
tree output for a snapshot hierarchy.  For example:

$ virsh snapshot-list dom --tree
root1
 |
  +- sibling1
  +- sibling2
  |   |
  |   +- grandchild
  |
  +- sibling3

root2
 |
  +- child

* tools/virsh.c (cmdSnapshotList): Add --tree.
* tools/virsh.pod (snapshot-list): Document it.

Make parent computation reusable, using virDomainSnapshotGetParent
when possible.

* tools/virsh.c (vshGetSnapshotParent): New helper.
(cmdSnapshotParent): Use it.

Mostly straight-forward, although this is the first API that
returns a new snapshot based on a snapshot rather than a domain.

* src/remote/remote_protocol.x
(REMOTE_PROC_DOMAIN_SNAPSHOT_GET_PARENT): New rpc.
(remote_domain_snapshot_get_parent_args)
(remote_domain_snapshot_get_parent_ret): New structs.
* src/rpc/gendispatch.pl: Adjust generator.
* src/remote/remote_driver.c (remote_driver): Use it.
* src/remote_protocol-structs: Update.

Although a client can already obtain a snapshot's parent by
dumping and parsing the xml, then doing a snapshot lookup by
name, it is more efficient to get the parent in one step, which
in turn will make operations that must traverse a snapshot
hierarchy easier to perform.

* include/libvirt/libvirt.h.in (virDomainSnapshotGetParent):
Declare.
* src/libvirt.c (virDomainSnapshotGetParent): New function.
* src/libvirt_public.syms: Export it.
* src/driver.h (virDrvDomainSnapshotGetParent): New callback.

Coupled with the recent virsh nodedev-* doc patch, this should now
give a better picture of libvirt node device handling.

* docs/formatnode.html.in: Fill in page.

This section of the man page was completely missing; I stumbled on
it when I had no clue that I had to use nodedev-reattach after
I was done playing with <hostdev> device passthrough to one of my
guests.

* tools/virsh.pod (NODEDEV COMMANDS): New section.
(attach-device, detach-device): Add cross-references.

This patch fixes the regression with using named pipes for qemu serial
devices noted in:

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

The problem was that, while new code in libvirt looks for a single
bidirectional fifo of the name given in the config, then relabels that
and continues without looking for / relabelling the two unidirectional
fifos named ${name}.in and ${name}.out, qemu looks in the opposite
order. So if the user had naively created all three fifos, libvirt
would relabel the bidirectional fifo to allow qemu access, but qemu
would attempt to use the two unidirectional fifos and fail (because it
didn't have proper permissions/rights).

This patch changes the order that libvirt looks for the fifos to match
what qemu does - first it looks for the dual fifos, then it looks for
the single bidirectional fifo. If it finds the dual unidirectional
fifos first, it labels/chowns them and ignores any possible
bidirectional fifo.

(Note commit d37c6a3a (which first appeared in libvirt-0.9.2) added
the code that checked for a bidirectional fifo. Prior to that commit,
bidirectional fifos for serial devices didn't work because libvirt
always required the ${name}.(in|out) fifos to exist, and qemu would
always prefer those.

Thus, when libvirtd is restarted, it will know if a domain is supposed
to be killed or reset when it shuts down.

If a domain started with -no-shutdown shuts down while libvirtd is not
running, it will be seen as paused when libvirtd reconnects to it. Use
the paused reason to detect if a domain was stopped because of shutdown
and finish the process just as if a SHUTDOWN event is delivered from
qemu.

Current qemu is able to give us detailed domain status (not just if it
is running or not) which we can translate into a status reason.

If migration failed in Prepare phase after virDomainAssignDef and before
a job was started, the domain object was not properly removed.

The AppArmor security driver adds only the path specified in the domain
XML for character devices of type 'pipe'. It should be using <path>.in
and <path>.out. We do this by creating a new vah_add_file_chardev() and
use it for char devices instead of vah_add_file(). Also adjust
valid_path() to accept S_FIFO (since qemu chardevs of type 'pipe' use
fifos). This is https://launchpad.net/bugs/832507

This patch cleans the cpu baseline function using new libvirt helper
functions and fixes XPath expression that selects <cpu> elements from
the source file, that can contain concatenated <capabilities> XMLs,
domain XMLs and bare <cpu> elements. The fixed XPath expression ensures
not to select NUMA <cpu id=... elements.

This patch also removes vshRealloc function, that remained unused after
cleaning up cpu-baseline.

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

This patch adds extraction of the <cpu> element from capabilities and
domain definition XML documents to improve user experience.

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

pod2man from perl-5.8.8 (RHEL 5) errors out on ill-formed POD:

*** ERROR: unterminated I<...> at line 1114 in file virsh.pod
*** ERROR: unterminated I<...> at line 1851 in file virsh.pod

Newer pod2man appears to be more tolerant (which is a shame,
because it meant that this error is harder to detect).

* tools/virsh.pod (undefine, snapshot-current): Add missing >.

This patch was made in response to:

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

In short, qemu's default for the rombar setting (which makes the
firmware ROM of a PCI device visible/not on the guest) was previously
0 (not visible), but they recently changed the default to 1
(visible). Unfortunately, there are some PCI devices that fail in the
guest when rombar is 1, so the setting must be exposed in libvirt to
prevent a regression in behavior (it will still require explicitly
setting <rom bar='off'/> in the guest XML).

rombar is forced on/off by adding:

  <rom bar='on|off'/>

inside a <hostdev> element that defines a PCI device. It is currently
ignored for all other types of devices.

At the moment there is no clean method to determine whether or not the
rombar option is supported by QEMU - this patch uses the advice of a
QEMU developer to assume support for qemu-0.12+. There is currently a
patch in the works to put this information in the output of "qemu-kvm
-device pci-assign,?", but of course if we switch to keying off that,
we would lose support for setting rombar on all the versions of qemu
between 0.12 and whatever version gets that patch.

Commit ecd8725c dropped attempts to probe the cgconfig service on
new enough Fedora where systemd took over that aspect of the system,
but mistakenly used F14 instead of F15 as the cutoff point.

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

Also, RHEL does not include HyperV support yet.

* libvirt.spec.in (with_cgconfig): Check cgconfig service in F15.
(%{?rhel}): Provide default for with_hyperv.

SIGTERM handling for -no-shutdown is already fixed in qemu git and
libvirt can safely use it. The downside is that 0.15.50 version of qemu
can be any qemu compiled from git, even that without the fix for
SIGTERM. However, I think this patch is worth it since excluding 0.15.50
from the check makes testing current qemu with libvirt much easier and
someone running qemu from git should be able to rebuild fixed qemu from
git if they hit the problem with a hang on shutdown.

Both --copy-storage-{all,inc} options require disk images to be present
on destination host.