Currently the QEMU monitor is given an FD to the logfile. This
won't work in the future with virtlogd, so it needs to use the
qemuDomainLogContextPtr instead, but it shouldn't directly
access that object either. So define a callback that the
monitor can use for reporting errors from the log file.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When the qemuProcessAttach/Stop methods write a marker into
the log file, they can use qemuDomainLogContextWrite to
write a formatted message.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of writing directly to a log file descriptor, change
qemuLogOperation to use qemuDomainLogContextWrite().
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemuDomainTaint APIs currently expect to be passed a log file
descriptor. Change them to instead use a qemuDomainLogContextPtr
to hide the implementation details.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the places which create/open log files to use the new
qemuDomainLogContextPtr object instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce a qemuDomainLogContext object to encapsulate
handling of I/O to/from the domain log file. This will
hide details of the log file implementation from the
rest of the driver, making it easier to introduce
support for virtlogd later.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There are two pretty similar functions qemuProcessReadLog and
qemuProcessReadChildErrors. Both read from the QEMU log file
and try to strip out libvirt messages. The latter then reports
an error, while the former lets the callers report an error.

Re-write qemuProcessReadLog so that it uses a single read
into a dynamically allocated buffer. Then introduce a new
qemuProcessReportLogError that calls qemuProcessReadLog
and reports an error.

Convert all callers to use qemuProcessReportLogError.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The rename operation only works on inactive virtual machines,
but it none the less writes to the log file used by the QEMU
processes. This log file is not intended to provide a general
purpose audit trail of operations performed on VMs. The audit
subsystem has recording of important operations. If we want
to extend that to cover all significant public APIs that is
a valid thing to consider, but we shouldn't arbitrarily log
specific APIs into the QEMU log file in the meantime.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Using qemuProcess{Init,Launch,FinishStartup} allows us to run
pre-migration commands on destination before asking QEMU to wait for
incoming migration data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

NBD storage migration will not work with offline migration anyway and we
already checked that the user did not ask for it. Thus it doesn't make
sense to keep the code after 'done' label where we jump in case of
offline migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Some failure paths in qemuMigrationPrepareAny forgot to kill the just
started QEMU process. This patch fixes this by combining 'stop' and
'endjob' label into a new label 'stopjob'. This name was chosen to avoid
confusion with the most common semantics of 'endjob'. Normally, 'endjob'
is always called at the end of an API to stop the job we entered at the
beginning. In qemuMigrationPrepareAny we only want to stop the job in
failure path; on success we need to carry the job over to the Finish
phase.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Finishes starting a new domain launched by qemuProcessLaunch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Once qemuProcessInit was called, qemuProcessLaunch will launch a new
QEMU process with stopped virtual CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is going to be split in three parts: qemuProcessInit,
qemuProcessLaunch, and qemuProcessFinish so that migration Prepare phase
can insert additional code in the process. qemuProcessStart will be a
small wrapper for all other callers.

qemuProcessInit prepares the domain up to the point when priv->qemuCaps
is initialized.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.

Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash

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

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.)

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

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.

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

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>