virsh subcommand memtune forgot updating domain live xml
after setting cgroup value.

A value which is equal to a integer maximum such as LLONG_MAX is
a valid integer value.

The patch fix the following error:
1, virsh memtune vm --swap-hard-limit -1
2, virsh start vm
In debug mode, it shows error like:
virScaleInteger:1813 : numerical overflow:\
                       value too large: 9007199254740991KiB

This patch adds proper error reporting if parsing of cputune parameters
fails due to incorrect values provided by the user. Previously no errors
were reported in such a case and the failure was silently ignored.

Make the iterator function usable in the next patches. Also refactor
some parts to avoid strcmp if not necessary.

This commit tweaks and shadows the change that was done in commit
babe7dad and was needed after the
support for multiple console devices was added. Historically the first
<console> element is alias for the <serial> device.

This patch changes many unrelated places to simplify the code or update
code style. This patch should not have any semantic impact on the code.

Help script creators by not having to parse the names from the table.

- configure.ac docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: merged in transifex updates for fr,hi,pl,ja,uk,it and
  regenerated

There is some controversy[1] on the qemu list on whether qemu should
have ever allowed arbitrary file name passthrough, or whether it
should be restricted to JUST /dev/random and /dev/hwrng.  It is
always easier to add support for additional filenames than it is
to remove support for something once released, so this patch
restricts libvirt 1.0.3 (where the virtio-random backend was first
supported) to just the two uncontroversial names, letting us defer
to a later date any decision on whether supporting arbitrary files
makes sense. Additionally, since qemu 1.4 does NOT support
/dev/fdset/nnn fd passthrough for the backend, limiting to just
two known names means that we don't get tempted to try fd
passthrough where it won't work.

[1]https://lists.gnu.org/archive/html/qemu-devel/2013-03/threads.html#00023

* src/conf/domain_conf.c (virDomainRNGDefParseXML): Only allow
/dev/random and /dev/hwrng.
* docs/schemas/domaincommon.rng: Flag invalid files.
* docs/formatdomain.html.in (elementsRng): Document this.
* tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-random.args:
Update test to match.
* tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-random.xml:
Likewise.

Added a picture and explanation describing the virConnectOpen processing
at a "higher" level, but with some source code references.

Change the order of some conditions and use the AllDomains API to get
a list of all the active and defined domains, then use the Active and
Name API's in order to print.

This changes here adjust the output from:

Attempting to connect to hypervisor
Connected to hypervisor at "qemu:///system"
Hypervisor: "QEMU" version: 0.32.656
There are 0 active and 2 inactive domains
Inactive domains:
  foo
  bar
Disconnected from hypervisor

to

Attempting to connect to hypervisor
Connected to hypervisor at "qemu:///system"
Hypervisor: "QEMU" version: 0.32.656
There are 0 active and 2 inactive domains
       foo (non-active)
       bar (non-active)
Disconnected from hypervisor

Update the function prototypes to include a message about the client needing
to free() returned name fields.  Fix the all domains example flags values.

When given a CA cert with basic constraints to set non-critical,
and key usage of 'key signing', this should be rejected. Version
of GNUTLS < 3 do not rejecte it though, so we never noticed the
test case was broken
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

19c6ad9a (qemu: Refactor qemuDomainSetMemoryParameters) introduced
a new macro, VIR_GET_LIMIT_PARAMETER(PARAM, VALUE). But if statement
in the macro is not correct and so set_XXXX flags are set to false
in the wrong. As a result, libvirt ignores all memtune parameters.
This patch fixes the conditional expression to work correctly.
Signed-off-by: NSatoru Moriya <satoru.moriya@hds.com>

BZ:https://bugzilla.redhat.com/show_bug.cgi?id=912021
Without error handler set, virDefaultErrorFunc will be called, the
error message is prefixed with "libvir:". It become a little better
by using prefix "libvirt:" when working with upper application.

For example:
1, stop libvirtd daemon
2, run virt-top.
libvir: XML-RPC error : Failed to connect \
        socket to '/var/run/libvirt/libvirt-sock-ro': \
        No such file or directory
libvirt: VIR_ERR_SYSTEM_ERROR: VIR_FROM_RPC: \
        Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': \
        No such file or directory

There's a quite old bug entry here:

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

I just stumbled over that very issue on F18. Doing a little bit
debugging of the shutdown sequence, it turns out that - at least on my
F18 installation - libvirtd is shutdown *after* iscsid, which makes it
impossible for libvirt to perform the logout of the iscsi session properly.

This patch simply adds another startup dependancy on iscsid.service
which in turn delays iscsid shutdown until after libvirtd has stopped.
Having that applied, the system shuts down properly again.
Signed-off-by: NEric Blake <eblake@redhat.com>

At the start of the guest after the image is unlinked the state wasn't
touched up to match the state on disk.

Commit f506a4c1 changed virSetUIDGID() to be a noop
when uid/gid are -1, while it used to be a noop when
they are <= 0.

The changes in this commit broke creating new VMs in GNOME Boxes
as qemuDomainCheckDiskPresence gets called during domain creation/startup,
which in turn calls virFileAccessibleAs which fails after calling
virSetUIDGID(0, 0) (Boxes uses session libvirtd). virSetUIDGID is called with
(0, 0) as these are the default user/group values in virQEMUDriverConfig
for session libvirtd.

This commit changes virQEMUDriverConfigNew to use -1 as the unpriviledged
uid/gid. I've also looked at the various places where cfg->user is used,
and they all seem to handle -1 correctly.

Adjust the docs accordingly. See http://bugs.debian.org/701570.

Currently, after we removed the qemu driver lock, it may happen
that two or more threads will start up a machine with macvlan and
race over virNetDevMacVLanCreateWithVPortProfile(). However,
there's a racy section in which we are generating a sequence of
possible device names and detecting if they exits. If we found
one which doesn't we try to create a device with that name.
However, the other thread is doing just the same. Assume it will
succeed and we must therefore fail. If this happens more than 5
times (which in massive parallel startup surely will) we return
-1 without any error reported. This patch is a simple hack to
both of these problems. It introduces a mutex, so only one thread
will enter the section, and if it runs out of possibilities,
error is reported. Moreover, the number of retries is raised to 20.

This reverts the hack done in

commit 568a6cda
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Fri Feb 15 15:11:47 2013 +0100

    qemu: Avoid deadlock in autodestroy

since we now have a fix which avoids the deadlock scenario
entirely

There is a lock ordering problem in the QEMU close callback
APIs.

When starting a guest we have a lock on the VM. We then
set a autodestroy callback, which acquires a lock on the
close callbacks.

When running auto-destroy, we obtain a lock on the close
callbacks, then run each callbacks - which obtains a lock
on the VM.

This causes deadlock if anyone tries to start a VM, while
autodestroy is taking place.

The fix is to do autodestroy in 2 phases. First obtain
all the callbacks and remove them from the list under
the close callback lock. Then invoke each callback
from outside the close callback lock.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When the auto-destroy callback runs it is supposed to return
NULL if the virDomainObjPtr is no longer valid. It was not
doing this for transient guests, so we tried to virObjectUnlock
a mutex which had been freed. This often led to a crash.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

qemuProcessStart expects to be run with a job already set and every
caller except for qemuMigrationPrepareAny use it correctly. This bug can
be observed in libvirtd logs during incoming migration as

    warning : qemuDomainObjEnterMonitorInternal:979 : This thread seems
    to be the async job owner; entering monitor without asking for a
    nested job is dangerous

With the apparmor security driver enabled, qemu instances fail
to start

# grep ^security_driver /etc/libvirt/qemu.conf
security_driver = "apparmor"
# virsh start test-kvm
error: Failed to start domain test-kvm
error: internal error security label already defined for VM

The model field of virSecurityLabelDef object is always populated
by virDomainDefGetSecurityLabelDef(), so remove the check for a
NULL model when verifying if a label is already defined for the
instance.

Checking for a NULL model and populating it later in
AppArmorGenSecurityLabel() has been left in the code to be
consistent with virSecuritySELinuxGenSecurityLabel().

As pointed out in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1034661
The sentence

"The function of PCI device addresses must less than 8"

does not quite make sense.  Update that to read

"The function of PCI device addresses must be less than 8"
Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>

Currently, qemuDomainShutdownFlags() chooses the agent method of
shutdown whenever the agent is configured. However, this
assumption is not enough as the guest agent may be unresponsive
at the moment. So unless guest agent method has been explicitly
requested, we should fall back to the ACPI method.

The unitialized local variable qemuVersion can cause an random value
to be returned for the hypervisor version, observable with virsh version.
Introduced by commit b46f7f4aSigned-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

disk->src is still used for disks->hosts->name, do not free it.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

* docs/formatnetwork.html.in: Spell variation correctly.

The QEMU driver has a list of devices nodes that are whitelisted
for all guests. The kernel has recently started returning an
error if you try to whitelist a device which does not exist.
This causes a warning in libvirt logs and an audit error for
any missing devices. eg

2013-02-27 16:08:26.515+0000: 29625: warning : virDomainAuditCgroup:451 : success=no virt=kvm resrc=cgroup reason=allow vm="vm031714" uuid=9d8f1de0-44f4-a0b1-7d50-e41ee6cd897b cgroup="/sys/fs/cgroup/devices/libvirt/qemu/vm031714/" class=path path=/dev/kqemu rdev=? acl=rw
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

s/VIR_QEMU_PROCESS_START_AUTODESROY/VIR_QEMU_PROCESS_START_AUTODESTROY/
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The code for putting the emulator threads in a separate cgroup
would spam the logs with warnings

2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3
2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4
2013-02-27 16:08:26.732+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6

This is because it has only created child cgroups for 3 of the
controllers, but was trying to move the processes from all the
controllers. The fix is to only try to move threads in the
controllers we actually created. Also remove the warning and
make it return a hard error to avoid such lazy callers in the
future.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>