Use I/O vector (iovec) instead of one huge memory buffer as suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1026137#c7. This avoids
doing memmove() to big buffers and performance doesn't degrade if
source (virNetClientStreamQueuePacket()) is faster than sink
(virNetClientStreamRecvPacket()).

Resolves: http://bugzilla.redhat.com/1026137Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

s/virDomainFindBy/virDomainObjListFindBy/
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>

If cpuset is disabled or not available, it libvirt must not use it.
Mainly for actions that do not need it and can use sched_setaffinity()
or numa_membind() instead, because they will fail without good reason.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1244664Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

When stopping a domain on the destination host after a failed migration,
we need to avoid reseting security labels since the domain is still
running on the source host. While we were correctly doing so in some
cases, there were still some paths which did this wrong.

https://bugzilla.redhat.com/show_bug.cgi?id=1242904Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In addition to checking the current asynchronous job
qemuMigrationJobIsActive reports an error if the current job does not
match the one we asked for. Let's just check the job directly since we
are not interested in the error in qemuProcessHandleMonitorEOF.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

If destination libvirt doesn't support memory hotplug since all the
support was introduced by adding new elements the destination would
attempt to start qemu with an invalid configuration. The worse part is
that qemu might hang in such situation.

Fix this by sending a required migration feature called 'memory-hotplug'
to the destination. If the destination doesn't recognize it it will fail
the migration.

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

So far qemu-nbd is run even if the nbd kernel module isn't loaded. This
leads to errors when the user starts his lxc container while libvirt
could easily load the nbd module automatically.

Our atomic increment (virAtomicIntInc) uses (if available) gcc
__sync_add_and_fetch builtin. In qemu driver though, we'd profit more
from __sync_fetch_and_add builtin. To keep it simplistic, this patch
adjusts qemu driver initialization rather than adding a new atomic
increment macro.

virDomainDeleteConfig is meant to delete the persistent config and thus
it resets vm->autostart. Copy parts of qemuProcessRemoveDomainStatus to
a new helper to avoid using the incorrect function.

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

The remoteDomainOpenGraphicsFD method was using the wrong RPC
arg struct remote_domain_open_graphics_args instead of
remote_domain_open_graphics_fd_args. Fortunately both structs
had identical contents so there was no functional bug, but to
avoid confusing future maintainers, we should fix it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

First hunk changes the use of srcdir to top_srcdir so it complies with
other rules in the Makefile.  Second one removes the need of
remote_protocol.h in admin_protocol.h as it was suggested and worked in,
but this one line was missed apparently.  Last one just removes the
'remote' naming from admin protocol specification, just so it's cleaner.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit d506a51a meant to check for
QEMU_CAPS_DRIVE_IOTUNE_MAX, but checked for QEMU_CAPS_DRIVE_IOTUNE
instead.  That's clearly visible from the diff, but it got in.  Because
of that, we were supplying information unknown for QEMU if it wasn't new
enough and we couldn't even properly handle the error, leading to
"Unexpected error".  Also iops_size came at the same time with all the
other "_max" options, so check whether we're not setting that either if
QEMU_CAPS_DRIVE_IOTUNE_MAX is not supported.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1224053Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 2094d01e forgot to rename two
more files.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Simplest was just to rename that extra long name and move files in git
accordingly

There are some non-0 default values in virDomainControllerDef (and
will soon be more) that are easier to not forget if the remembering is
done by a single initializer function (rather than inline code after
allocating the obejct with generic VIR_ALLOC().

This loop occurs just after we've assured that all devices that
require a PCI device have been assigned and all necessary PCI
controllers have been added. It is the perfect place to add other
potentially auto-generated PCI controller attributes that are
dependent on the controller's PCI address (upcoming patch).

There is a convenient loop through all controllers at the end of the
function, but the patch to add new functionality will be cleaner if we
first rearrange that loop a bit.

Note that the loop originally was accessing info.addr.pci.bus prior to
determining that the pci part of the object was valid. This isn't
dangerous in any way, but seemed a bit ugly, so I fixed it.

The function that auto-assigns PCI addresses was written with the
hardcoded assumptions that any PCI bus would have slots available
starting at 1 and ending at 31. This isn't true for many types of
controllers (some have a single slot/port at 0, some have slots/ports
from 0 to 31). This patch updates that function to remove the
hardcoded assumptions. It will properly find/assign addresses for
devices that can only connect to pcie-(root|downstream)-port (which
have minSlot/maxSlot of 0/0) or a pcie-switch-upstream-port (0/31).

It still will not auto-create a new bus of the proper kind for these
connections when one doesn't exist, that task is for another day.

Add a testcase for the previous change to ensure zero capacity volumes can be
defined without a backing store.
Signed-off-by: NChris J Arges <chris.j.arges@canonical.com>

In commit 155ca616, a change was introduced that no longer allowed defining
volumes via XML with a capacity of '0'. Because we check for info.size_arg
to be non-zero, this use-case fails. This patch allows info.size_arg to be
zero if no backing store is specified.
Signed-off-by: NChris J Arges <chris.j.arges@canonical.com>

Commit id 'ac3ed208' causes 'virsh nodedev-list --cap net' to fail
on any system without SYSFS_INFINIBAND_DIR (/sys/class/infiniband).

Rather than assume it's there and fail on the attempt to open the
non-existent directory, check if it's there - if not, return
success and move on. Also fix caller to check < 0 upon return.

As reported by Suren Hajyan <shajyan@redhat.com> from run of unit tests

Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>

This reverts commit 7b401c3b.

Until libvirt is able to differentiate whether heads='1' is just a
leftover from previous libvirt or whether that's added by user on
purpose and also whether the domain was started with the support for
qxl's max_outputs, we cannot incorporate this patch into the tree
due to compatibility reasons.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

As there is a regression in use vcpupin get info, introduce a new function
to test the virsh client.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

This makes the range and static host array management in
virNetworkDHCPDefParseXML() more similar to what is done in
virNetworkDefUpdateIPDHCPRange() and virNetworkDefUpdateIPDHCPHost() -
they use VIR_APPEND_ELEMENT rather than a combination of
VIR_REALLOC_N() and separate incrementing of the array size.

The one functional change here is that a memory leak of the contents
of the last (unsuccessful) virNetworkDHCPHostDef was previously leaked
in certain failure conditions, but it is now properly cleaned up.

Bhyve as of r279225 (FreeBSD -CURRENT) or r284894 (FreeBSD 10-STABLE)
supports using UTC time offset via the '-u' argument to bhyve(8). By
default it's still using localtime.

Make the bhyve driver use UTC clock if it's requested by specifying
<clock offset='utc'> in domain XML and if the bhyve(8) binary supports
the '-u' flag.

Commit ac3ed208 breaks build on FreeBSD with:

  CC       util/libvirt_util_la-virnetdev.lo
util/virnetdev.c:2967:1: error: unused function 'virNetDevRDMAFeature' [-Werror,-Wunused-function]
virNetDevRDMAFeature(const char *ifname,
^

So hide virNetDevRDMAFeature function under the #ifdef 'SIOCETHTOOL'
and 'HAVE_STRUCT_IFREQ' section.

Pushed under the build breaker rule.

We don't need pkcheck binary, but we must detect it in order
to see if we're preferring polkit-1 over polkit-0 when both
are installed. We should also check $with_dbus to see if we
have dbus-devel available, as that's required to talk to
polkit-1.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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

We won't return the errno after commit 0d7f45ae, and
the more clearly error will be set in the code in vircgroup*.
Also We will always report error "Operation not permitted",
because the return is -1.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Move the calls to the respective functions from virNodeParseNode(),
which is executed once for every NUMA node, to
linuxNodeInfoCPUPopulate(), which is executed just once per host.

Keep track of what CPUs belong to the current node while walking
through the sysfs node entry, so we don't need to do it a second
time immediately afterwards.

This also allows us to loop through all CPUs that are part of a
node in guaranteed ascending order, which is something that is
required for some upcoming changes.

No need to look up the online status of each CPU separately when we
can get all the information in one go.

Swap out all instances of cpu_set_t and replace them with virBitmap,
which some of the code was already using anyway.

The changes are pretty mechanical, with one notable exception: an
assumption has been added on the max value we can run into while
reading either socket_it or core_id.

While this specific assumption was not in place before, we were
using cpu_set_t improperly by not making sure not to set any bit
past CPU_SETSIZE or explicitly allocating bigger bitmaps; in fact
the default size of a cpu_set_t, 1024, is way too low to run our
testsuite, which includes core_id values in the 2000s.

The new name makes it clear that the returned bitmap contains the
information about which CPUs are online, not eg. which CPUs are
present.

No behavioral change.

Not all users of this API will need the size of the returned
bitmap; those who do can simply call virBitmapSize() themselves.