The `virTypedParamsAddStringList' function provides interface to add a
NULL-terminated array of string values as a multi-value to the params.
Signed-off-by: NPavel Boldin <pboldin@mirantis.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add multikey API:

 * virTypedParamsFilter that filters all the parameters with specified name.
 * virTypedParamsGetStringList that returns a list with all the values for
   specified name and string type.
Signed-off-by: NPavel Boldin <pboldin@mirantis.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Allow multi-value parameters to be build using virTypedParamsAdd*
functions by removing check for duplicates.
Signed-off-by: NPavel Boldin <pboldin@mirantis.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The `virTypedParamsValidate' function now can be instructed to allow
multiple entries for some of the keys. For this flag the type with
the `VIR_TYPED_PARAM_MULTIPLE' flag.

Add unit tests for this new behaviour.
Signed-off-by: NPavel Boldin <pboldin@mirantis.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When playing with disk migration lately, I've noticed this warning in
domain logs:

WARNING: Image format was not specified for 'nbd://masina:49153/drive-virtio-disk0' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

So I started digging into qemu source code to see what has triggered
the warning. I'd expect qemu to know formats of guest's disks since we
tell them on command line. This lead me to qmp_drive_mirror() where
the following can be found:

    if (!has_format) {
        format = mode == NEW_IMAGE_MODE_EXISTING ? NULL : bs->drv->format_name;
    }

So, format is automatically initialized from the disk iff mode !=
"existing". Unfortunately, in migration we are tied to use this mode
(NBD doesn't support creating new images). Therefore the only way to
avoid this warning is to pass format. The discussion on the mail-list [1]
resulted in the code that always forces NBD export as "raw" format.

[1] https://www.redhat.com/archives/libvir-list/2015-June/msg00153.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NPavel Boldin <pboldin@mirantis.com>

This function is returning a string (domain XML). Since d3ce7363
when it was first introduced, it was indented incorrectly:

static char
*qemuMigrationBeginPhase(..)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The disk is not changed anywhere in the function. Mark this fact
in the function header too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If virDomainObjGetDefs used in qemuDomainPinIOThread would fail the code
would jump to the 'cleanup' label after acquiring the job, thus the VM
would be locked forever.

Introduced in commit cac6d639.

The privileged flag will not change while the configuration might
change. Make the 'privileged' flag member of the driver again and mark
it immutable. Should that ever change add an accessor that will group
reads of the state.

Simplify the code by restructuring control flow and reusing the better
helper.

Replace the for loops with case inside with temp variables and a macro.

Use virDomainObjGetDefs and sanitize the control flow.

virDomainObjGetOneDef is simpler to use than virDomainObjGetDefs

virDomainObjGetOneDef is simpler to use than virDomainObjGetDefs

virDomainObjGetOneDef is simpler to use than virDomainObjGetDefs

virDomainObjGetOneDef will help to retrieve the correct definition
pointer from @vm in cases where VIR_DOMAIN_AFFECT_LIVE and
VIR_DOMAIN_AFFECT_CONFIG are mutually exclusive. The function simply
returns the correct pointer. This similarly to virDomainObjGetDefs will
greatly simplify the code.

If @flags contains only VIR_DOMAIN_AFFECT_CONFIG and @vm is active, the
function would return the active config rather than the persistent one
that it should return. This happened due to the fact that
virDomainObjGetDefs was checking the updated flags which may not contain
VIR_DOMAIN_AFFECT_LIVE if it is not requested even if @vm is active.

Additionally the function would not take the flags into account when
setting the pointers which was later used to determine whether the code
needs to update the given configuration.

The mistake was caught by the virt-test suite.

I needed to specify the iobase address for certain exotic mips configurations.
Signed-off-by: NJames Cowgill <james410@cowgill.org.uk>

When hotplugging a memory device, there wasn't a check to determine
if there is a conflict with the address space being used by the to
be added memory device and any existing device which is disallowed by qemu.

This patch adds a check to ensure the new device address doesn't
conflict with any existing device.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

If the admin service is disabled it would not be allocated, but the NULL
pointer still would be added to the admin server. Since
virNetServerAddService would dereference it, the daemon would crash.

Move the service registration into the block that allocates it.

VIR_APPEND_ELEMENT would clear @srv to NULL after it successfully
inserted it thus the reference count could not be increased afterwards.

Switch to VIR_APPEND_ELEMENT_COPY. This fixes crash after terminating
the daemon.

There was many errors in libvirt.log caused by prlsdkDelNet function because
job variable was always initialized as PRL_INVALID_HANDLE
In this patch job variable gets return value of PrlSrv_DeleteVirtualNetwork function()

We need to initialize buflen every time when we get network adapter's
friendly name because we call PrlVmDev_GetFriendlyName in a loop

If the address type is SPAPRVIO, it will match the != NONE condition.

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

This type of information defines attributes of a system
baseboard. With one exception: board type is yet not implemented
in qemu so it's not introduced here either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some machine types are only reported as canonical names for other
machine types, which make it a bit harder to find what machine types are
supported by a specific QEMU binary. Ideally, one would just use
/capabilities/guest/arch[@name='...']/machine/text() XPath to get a list
of all supported machine types, but it doesn't work right now.

For example, we report

    <machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine>

in guest capabilities, but the corresponding

    <machine maxCpus='255'>pc-i440fx-2.3</machine>

is missing.

This is a result of QMP probing. With "-machine ?" parsing QEMU sends
us two lines:

pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.3)
pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996) (default)

while query-machines QMP command reports both in the same entry:

{"name": "pc-i440fx-2.3", "is-default": true, "cpu-max": 255, "alias": "pc"}

Let's make sure we always report separate <machine/> for both the
canonical name and its alias and using the canonical name as the default
machine type (i.e., inserting it before its alias) in case is-default is
true.

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

We tend to keep the folders in the EXTRA_DIST sorted alphabetically.
However, we've failed sometimes and the list is not ordered anymore.
Reorder it back.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So, it's a little paradox that we use the file twice. Firstly to build
libvirt-admin.la (a client side of the Admin API), then once again to
build the server side. Well, the problem is, this does not play nicely
with the distclean since the file is generated. So while it's removed
in the src/ the distclean running in daemon/ will not find the file
and fail. The file is needed because it contains the RPC wrappers. So
let's leave the client code as is and from the daemon/ just link the
client library. The linker will find desired symbols and use them.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As with several other attributes of devices (link status, sriov VF
list, IOMMU group list), the detdev feature bits aren't automatically
updated in the nodedev driver's cache when they change. In order to
get a properly up-to-date list when getting the XML of a device, we
must reget them in update-caps prior to each dumpxml.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1232880

While Martin introduced the binary (and its manpage) in commit
4e7ccf87 it was pushed by mistake. Therefore it was reverted in
220393bf. The problem is, the original commit was not quite right
as the binary was added into the spec file in a different commit:
55e0c840. So as long as the binary does not exist, we must remove it
from the spec file too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In a4746114 the virnetserver test was renamed to virnetdaemon.
Moreover, as the test relies on some data stored under
virnetserverdata/ the folder was renamed too. But this was not
reflected in the Makefile. Therefore when building outside of the
repository, the data folder was not distributed and test failed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The Admin API consists of a few files on daemon side. Notably
daemon/admin_server.{ch}. While they are both on the repo, only
the .c file is mentioned in Makefile. Therefore, .h is not
distributed and 'make rpm' fails.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since we have changed the name of the driver to vz, let's
reference it as vz everywhere.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

This patch moves all src/parallels/parallels* files to vz/vz*
and fixes build accordingly.
No functional changes.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Here we stop referencing vz driver by different names
in error messages. 'parallels driver', 'Parallels Cloud
Server', 'Parallels driver' all become just 'vz driver'.
No functional changes. Only renaming and a bit of rewording.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>