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>

This patch changes all parallels/vz driver structure and
function prefixes from parallels to vz.
No functional changes.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

In latest patches we added Admin API. However, the Makefile in daemon
was missing one dependency: admin_server.c is including generated file
admin_dispatch.h. However, this dependency was not explicitly marked
in the Makefile therefore the build happened to fail on some
occasions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This happens if user requires creation of a directory with specified
UID/GID permissions. To accomplish this, we use fork approach and
set particular UID/GID permissions in child process. However, child
process doesn't have a valid descriptor to a logfile (this is prohibited
explicitly) and since parent process doesn't handle negative exit codes from
child in any way, 'uknown cause' error is returned to the user.

Commit 92d9114e tweaked the way we handle child errors when using fork
approach to set specific permissions (features originally introduced
by 98f6f381). The same logic should be used to create directories with
specified permissions as well.

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

Previous patch of this series proposed a fix to virDirCreate, so that parent
process reports an error if child process failed its task.
However our logic still permits the child to exit with negative errno followed
by a check of the status on the parent side using WEXITSTATUS which, being
POSIX compliant, takes the lower 8 bits of the exit code and returns is to
the caller. However, by taking 8 bits from a negative exit code
(two's complement) the status value we read and append to stream is
'2^8 - abs(original exit code)' which doesn't quite reflect the real cause when
compared to the meaning of errno values.

Future kernels will mandate the use of nosuid+nodev+noexec
flags when mounting the /proc/sys filesystem. Unconditionally
add them now since they don't harm things regardless and could
mitigate future security attacks.

Commit id 'e44b0269' in advertently checked !dir before calling closedir