'maxcpu' and 'vcpus' are set but not used after that

When use setvcpus command with --guest option to a offline vm,
we will get error:

 # virsh setvcpus test3 1 --guest
 error: Guest agent is not responding: QEMU guest agent is not connected

However guest is not running, agent status could not be connected.
In this case, report domain is not running will be better than agent is
not connected. Move the guest status check more early to output error to
point out guest status is not right.

Also from the logic, a running vm is a basic requirement to use
agent, we cannot use agent if vm is not running.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We set @hostcpus variable but not use it.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

We support only one IPv4 and one IPv6 default gateway.
If static IPs are not present in instance config,
then we switch on DHCP for this adapter.
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.

There should be at least one domain for each guest
in cababilities. And in current code we don't add
domain for this guest for example.

    if ((guest = virCapabilitiesAddGuest(caps, VIR_DOMAIN_OSTYPE_HVM,
                                         VIR_ARCH_X86_64,
                                         "vz",
                                         NULL, 0, NULL)) == NULL)

Anyway, with two virt types it looks a litte messy, so let's
move adding guest and domain to a separate function.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Since the query string could be output when displaying the results too

Raised by https://www.xssposed.org/incidents/69566/
Need to escape the user provided query before displaying it back

Current version of SDK event dispatcing is incorrect. For most VM events (add,
delete etc) issuer type is PIE_DISPATCHER. Actually analyzing issuer type
doesn't have any benifints so this patch get rid of it. All dispatching is done
only on event type.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Avoid a false positive since Coverity find a path in virResizeN which
could return 0 prior to the allocation of memory and thus flags a
possible NULL dereference. Instead allocate the output buffer based
on 'nparams' and only fill it partially if need be - shouldn't be too
much a waste of space. Quicker than multiple VIR_RESIZE_N calls or
two loops of STREQ's sandwiched around a single VIR_ALLOC_N using
'n' matches from a first loop to generate the 'n' addresses to return
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '81dd81e4' caused a regression when attempting to print a
specific vcpuid that is out of the range of the maximum vcpus for
the guest, such as:

 $ virsh vcpupin $dom 1000
 VCPU: CPU Affinity
 ----------------------------------

 $

Rather than just recover the old message, let's adjust the message based
on what would be displayed for a similar failure in the set path, such as:

 $ virsh vcpupin $dom 1000
 error: vcpu 1000 is out of range of persistent cpu count 2

 $ virsh vcpupin $dom 1000 --live
 error: vcpu 1000 is out of range of live cpu count 2

 $
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

QEMU working in vhost-user mode communicates with the other end (i.e.
some virtual router application) via unix domain sockets. This requires
that permissions for the socket files are correctly written into
/etc/apparmor.d/libvirt/libvirt-UUID.files.
Signed-off-by: NMichal Dubiel <md@semihalf.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Sorted feature list is easier to review or compare.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated

Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverDir to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>