The return value has non-obvious semantics. Document it.

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

The checked predicate is a deduction from the following checks:

1) maximum cpu id is checked for every parsed <vcpusched> element
2) the resulting bitmaps are checked for overlaps
3) there has to be at least one cpu per <vcpusched>

From the above checks we can indeed deduce that if we have one
<vcpusched> element per CPU we will have at most 'maxvcpus' of them.

Drop the explicit check since it's redundant.

Now that new domains are started inside a QEMU_ASYNC_JOB_START job,
we need to pass it down to qemuProcessStartCPUs too.

This removes the warning:
qemuDomainObjEnterMonitorInternal:1750 : This thread seems to be the
async job owner; entering monitor without asking for a nested job is
dangerous

Introduced by commit 04c721f2, before that this code path was only
executed with QEMU_ASYNC_JOB_NONE.

(This code is not executed on migration, because qemuMigrationPrepareAny
 sets the VIR_QEMU_PROCESS_START_PAUSED flag.)

To simplify further refactors change the way the vcpu count is extracted
to use a temp variable rather than juggling with def->maxvcpus.

To simplify further refactors change the way the vcpu count is extracted
to use a temp variable rather than juggling with def.maxvcpus.

To simplify further refactors change the way the vcpu count is extracted
to use a temp variable rather than juggling with def->maxvcpus.

Use the helper that is necessary to fill out some values rather than
allocating it directly.

Signed-off-by: NJán Tomko <jtomko@redhat.com>

We do not have a pointer to the device here, just its source.

The domain definition is not needed in any of these functions.
Only pass it to qemuSetupChardevCgroup, which is used as a callback
for virDomainChrDefForeach.

Use the right type for passing virDomainObjPtr instead of
void* where possible.

Change CGroup to Cgroup to match other functions in the file.

like I440FX by moving the condition into qemuDomainMachineHasBuiltinIDE
and adding more machines.

Reference: http://bugs.debian.org/805189

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

Rather than using just open on the path, allow for the possibility that
the path to be opened resides on an NFS root-squash target and was created
under a different uid/gid.

Without using virFileOpenAs an attempt to get the volume size data may fail
if the current user doesn't have permissions to read the volume, such as
would be the case if mode wasn't supplied in the volume XML and the default
VIR_STORAGE_DEFAULT_VOL_PERM_MODE (e.g. 0600) was used. Under this scenario
the owner/group is not root:root, thus this path run under root would fail
to open/read the volume.

NB: The virFileOpenAs code using OPEN_FORK will only work when the failure
is not EACESS/EPERM and the path resolves to a shared file system.

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

Although commit id '77346f27' resolves part of the problem regarding creating
a qemu-img image in an NFS root-squash environment, it really didn't fix the
entire problem. Unfortunately it only masked the problem. It seems qemu-img
must open/create the image using 0644, which if used by target.perms would
result in the chmod not being called since the mode desired and set match.

Although qemu-img could conceivably ignore the mode when creating, libvirt
has more knowledge of the environment and can make the adjustment to the
mode far more easily by using virFileOpenAs with VIR_FILE_OPEN_FORCE_MODE.
If that's successful, then we know on return the file will have the right
owner and mode, so we can declare success

Unlike other architectures, ppc64 domains need to lock memory
even when VFIO is not used.

Change qemuDomainRequiresMlock() to reflect this fact.

The amount of memory a ppc64 domain might need to lock is different
than that of a equally-sized x86 domain, so we need to check the
domain's architecture and act accordingly.

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

The function is used everywhere else to check whether the locked
memory limit should be set / updated, and it should be used here
as well.

Moreover, qemuDomainGetMlockLimitBytes() expects the hostdev to
have already been added to the domain definition, but we only do
that at the end of qemuDomainAttachHostPCIDevice(). Work around
the issue by adding the hostdev before adjusting the locked memory
limit and removing it immediately afterwards.

This removes a duplication of the logic used to decide whether
the memory locking limit should be set.

This can be useful for debugging.

Commit 6472e54a unlocks the virDomainObj even if libxlDomainObjEndJob
returns false, indicating that its refcnt has dropped to 0.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Commits b6e19cf4 and 6472e54a missed unref'ing the
libxlDriverConfig object. Add missing calls to virObjectUnref.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Commit id '08600de3' changed the prototype to reduce an argument, but
didn't adjust the ATTRIBUTE_NONNULL(11) to (10)

Diff from v1.
1. Add virCheckFlags() call in vzDomainReboot

In virtuozzo we support only en-us keymap for VMs and containers.
If keymap is specified than check that it's en-us, otherwise
show error message.

Remembering to call qemuMonitorSetDomainLog in the right paths before
calling qemuProcessStop is annoying and easy to forget. And I already
forgot to do so in commit v1.2.8-52-g03890605: logfd may be leaked if
QEMU process dies between Prepare and Finish migration phases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Every caller setting migrateFrom already sets
VIR_QEMU_PROCESS_START_PAUSED flag anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessMakeDir is used for creating a per-domain directory in a
given parent directory.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Move {Enter,Exit}Monitor calls inside qemuProcessSetLinkStates to
simplify qemuProcessStart.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Traditionally, we pass incoming migration URI on QEMU command line,
which has some drawbacks. Depending on the URI QEMU may initialize its
migration state immediately without giving us a chance to set any
additional migration parameters (this applies mainly for fd: URIs). For
some URIs the monitor may be completely blocked from the beginning until
migration is finished, which means we may be stuck in qmp_capabilities
command without being able to send any QMP commands.

QEMU solved this by introducing "defer" parameter for -incoming command
line option. This will tell QEMU to prepare for an incoming migration
while the actual incoming URI is sent using migrate-incoming QMP
command. Before calling this command we can normally talk to the
monitor and even set any migration parameters which will be honored by
the incoming migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We only started an async job for incoming migration from another host.
When we were starting a domain from scratch or restoring from a saved
state (migration from file) we didn't set any async job. Let's introduce
a new QEMU_ASYNC_JOB_START for these cases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Incoming migration may require quite a few parameters (URI, fd, path) to
be considered while starting QEMU and we will soon add another one.
Let's group all of them in a single struct.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Make callers of qemuBuildCommandLine responsible for providing the URI
which should be passed as a parameter for -incoming.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>