Otherwise 'Unknown' error will be returned to client.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

When either creating a threadpool, or creating a new thread to accomplish a job
that had been placed into the jobqueue, every time thread-specific data need to
be allocated, threadpool needs to be (re)-allocated and thread count indicators
updated. Make the code clearer to read by compressing these operations into a
more complex one.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Make all relevant changes to admin protocol, in order to achieve $(subj)
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Commits 0472cef6, 9afc115f, 8cd1d546 exported typed params handlers internally,
but a commit which would move the public definition from libvirt-host to
libvirt-common was missing.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Use verify to force adding new events by means of static assertions.

When adding the static check I've noticed that one other event is
missing.

Rather than copying loads of ugly code, let's help out by a few C
tricks.

Avoid forgetting to add the correct fields to the switches in
event-test.

Make them return "uknown" for invalid values without breaking compiler
checks to add new values.

Arrays would induce crash if a new value was introduced without adding
it here. This could happen for
VIR_DOMAIN_EVENT_DISK_DROP_MISSING_ON_START

Break long lines and format headers correctly.

The event test does not try to include libvirt internals. Using a macro
named VIR_DEBUG might hint to such usage. Additionally it's useless
since it's used only in the main() function.

Modernize the message strings while touching them.

Most of the functions are no longer in this file. 'usage' does not need
a declaration.

virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:

We have only 2 keys
A  (multiples allowed)
B  (multiples NOT allowed)

We are given the following list of parameters to check:
A
A
B

If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"

This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.

In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.

virsh migrate --live guestname --copy-storage-all
              --migrate-disks vdb,vdc,vdd,vde,vdf
              qemu+ssh://dsthost/systemSigned-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: NEric Farman <farman@linux.vnet.ibm.com>

Migration API allows to specify a destination domain configuration.
Offline domain has only inactive XML and it is replaced by configuration
specified using VIR_MIGRATE_PARAM_DEST_XML param. In case of live
migration VIR_MIGRATE_PARAM_DEST_XML param is applied for active XML.

This commit introduces the new VIR_MIGRATE_PARAM_PERSIST_XML param
that can be used within live migration to replace persistent/inactive
configuration.

Required for: https://bugzilla.redhat.com/show_bug.cgi?id=835300

This changes allow to use qemuMigrationCookieAddPersistent with
an XML definition that isn't assigned to any domain.

By default, `zfs create -V ...` reserves space for the entire volsize,
plus some extra (which attempts to account for overhead).

If `zfs create -s -V ...` is used instead, zvols are (fully) sparse.

A middle ground (partial allocation) can be achieved with
`zfs create -s -o refreservation=... -V ...`.  Both libvirt and ZFS
support this approach, so the ZFS storage backend should support it.
Signed-off-by: NRichard Laager <rlaager@wiktel.com>

Commit id '4b75237f' seems to have triggered Coverity into finding
at least one memory leak in xen_xl.c for error path for cleanup where
the listenAddr would be leaked. Reviewing other callers, it seems that
qemu_parse_command.c would have the same issue, so just it too.

Coverity found that commit id 'c661b675' needed to create a cleanup
path to handle the closing of 'fp' if the virBitmapNewQuiet failed.

Commit id '0da965c5' removed the 11th parameter, but neglected to
remove the ATTRIBUTE_NONNULL for it and adjust the 17th and 18th.

To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since Xen 4.2, but
currently it does not make use of any changes made to existing
APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
The version can be bumped if/when the libxl driver consumes the
changed APIs.

Further details can be found in the following discussion thread

https://www.redhat.com/archives/libvir-list/2016-April/msg00178.htmlSigned-off-by: NJim Fehlig <jfehlig@suse.com>

When creating the master key, we used mode 0600 (which we should) but
because we were creating it as root, the file is not readable by any
qemu running as non-root.  Fortunately, it's just a matter of labelling
the file.  We are generating the file path few times already, so let's
label it in the same function that has access to the path already.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Recent patches addiing support for ploop volumes did not properly update
gluster backend.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In a few places in libvirt we busy-wait for events, for example qemu
creating a monitor socket.  This is problematic because:

 - We need to choose a sufficiently small polling period so that
   libvirt doesn't add unnecessary delays.

 - We need to choose a sufficiently large polling period so that
   the effect of busy-waiting doesn't affect the system.

The solution to this conflict is to use an exponential backoff.

This patch adds two functions to hide the details, and modifies a few
places where we currently busy-wait.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

In case of ploop volume, target path of the volume is the path to the
directory that contains image file named root.hds and DiskDescriptor.xml.
While using uploadVol and downloadVol callbacks we need to open root.hds
itself.
Upload or download operations with ploop volume are only allowed when
images do not have snapshots. Otherwise operation fails.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Refreshes meta-information such as allocation, capacity, format, etc.
Ploop volumes differ from other volume types. Path to volume is the path
to directory with image file root.hds and DiskDescriptor.xml.
https://openvz.org/Ploop/format
Due to this fact, operations of opening the volume have to be done once
again. get the information.

To decide whether the given volume is ploops one, it is necessary to check
the presence of root.hds and DiskDescriptor.xml files in volumes' directory.
Only in this case the volume can be manipulated as the ploops one.
Such strategy helps us to resolve problems that might occure, when we
upload some other volume type from ploop source.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Returns error in case of vol-wipe cmd for a ploop volume
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Changes the size of given ploop volume via ploop resize tool.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Recursively deletes whole directory of a ploop volume.
To delete ploop image it has to be unmounted.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

These callbacks let us to create ploop volumes in dir, fs and etc. pools.
If a ploop volume was created via buildVol callback, then this volume
is an empty ploop device with DiskDescriptor.xml.
If the volume was created via .buildFrom - then its content is similar to
input volume content.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Ploop image consists of directory with two files: ploop image itself,
called root.hds and DiskDescriptor.xml that contains information about
ploop device: https://openvz.org/Ploop/format.
Such volume are difficult to manipulate in terms of existing volume types
because they are neither a single files nor a directory.
This patch introduces new volume type - ploop. This volume type is used
by ploop volume's exclusively.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>