These uses of virGetLastError message are just duplicating
virGetLastErrorMessage.

Use qemuProcessCreatePretendCmd instead duplicating required steps from
qemuProcessStart.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Move all code that checks host and domain.  Do not check host if we use
VIR_QEMU_PROCESS_START_PRETEND flag.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This change is required by following patches.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In post-copy mode none of the hosts has a complete guest state and
rolling back migration is impossible. Thus aborting it would be
equivalent to destroying the domain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NCristian Klein <cristiklein@gmail.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

It's just a combination of AddImplicitControllers, and AddConsoleCompat.
Every caller that wants ImplicitControllers also wants the ConsoleCompat
AFAICT, so lump them together. We also need it for future patches.

We include the file in plenty of places. This is mostly due to
historical reasons. The only place that needs something from the
header file is storage_backend_fs which opens _PATH_MOUNTED. But
it gets the file included indirectly via mntent.h. At no other
place in our code we need _PATH_.*. Drop the include and
configure check then.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Mostly it is just passing new parameter here and there. In case
of zero value we fallback to auto selecting port and thus keep
backward compatibility.

Also we need to fix places of auto selected port managment.
We should bother only when auto selected was done that is
when externally specified port is not 0.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

In qemuConnectDomainXMLToNative() we set up the monitor, but we never
memset() it to zeros.  Thanks to the introduction of the logfile
parameter of chardevs (and the logfile member of the struct), we started
checking whether that's non-NULL and that exposed this old error.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

These functions already report fine grained errors, there's no
benefit to overwriting the error here.

Reverting to a snapshot may change domain configuration. New
configuration should be saved if domain has persistent flag.

VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT is emitted in case of
configuration update.

If use of virtlogd is enabled, then use it for backing the
character device log files too. This avoids the possibility
of a guest denial of service by writing too much data to
the log file.

After adding support for offline vcpu pinning the code that removes the
pinning for cpu cold-unplug was forgotten. This fixes up commit 02ae21de

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

Memory returned from virStringSplit shall be freed with
virStringFreeList rather than VIR_FREE. Introduced in commit 511e7c5b.

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

Now that the function was extracted we can get rid of some temp
variables. Additionally formatting of the bitmap string for the event
code should be checked.

The function was now beyond maintainability.

Allow pinning for inactive vcpus. The pinning mask will be automatically
applied as we would apply the default mask in case of a cpu hotplug.

Setting the scheduler settings for a vcpu has the same semantics.

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

The implementation of the inner guts of the function is similar for all
drivers, so we can add a helper and not have to reimplement it three
times.

We would happily report and free statistics of a completed migration
even before it actually completed (on the source host while migration is
in the Finish phase).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The code does not handle renaming of the save state file. In addition to
that the resuming code would need to be tweaked to handle the name
change since the XML is extracted from the save image. The easies option
is to make the rename API even less useful by forbiding this.

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

While trying to build with -Os couple of compile errors showed
up.

conf/domain_conf.c: In function 'virDomainChrRemove':
conf/domain_conf.c:13666:24: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virDomainChrDefPtr ret, **arrPtr = NULL;
                        ^
Compiler fails to see that @ret is used only if set in the loop,
but whatever, there's no harm in initializing the variable.

In vboxAttachDrivesNew and _vboxAttachDrivesOld compiler thinks
that @rc may be used uninitialized. Well, not directly, but maybe
after some optimization. Yet again, no harm in initializing a
variable.

In file included from ./util/virthread.h:26:0,
                 from ./datatypes.h:28,
                 from vbox/vbox_tmpl.c:43,
                 from vbox/vbox_V3_1.c:37:
vbox/vbox_tmpl.c: In function '_vboxAttachDrivesOld':
./util/virerror.h:181:5: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virReportErrorHelper(VIR_FROM_THIS, code, __FILE__,              \
     ^
In file included from vbox/vbox_V3_1.c:37:0:
vbox/vbox_tmpl.c:1041:14: note: 'rc' was declared here
     nsresult rc;
              ^
Yet again, one uninitialized variable:

qemu/qemu_driver.c: In function 'qemuDomainBlockCommit':
qemu/qemu_driver.c:17194:9: error: 'baseSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         qemuDomainPrepareDiskChainElement(driver, vm, baseSource,
         ^

And another one:

storage/storage_backend_logical.c: In function 'virStorageBackendLogicalMatchPoolSource.isra.2':
storage/storage_backend_logical.c:618:33: error: 'thisSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                       thisSource->devices[j].path))
                                 ^
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Reporting status of a control connection makes no sense for an inactive
domain.

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

Migration statistics are not available on the destination host and
starting a query job during incoming migration is not allowed. Trying to
do that would result in

    Timed out during operation: cannot acquire state change lock (held
    by remoteDispatchDomainMigratePrepare3Params)

error. We should not even try to start the job.

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

Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

We honour the placement bitmaps when starting up, so there's no point in
having this check. Additionally the check was buggy since it checked
vm->def all the time even if the user requested to modify the persistent
definition which had different configuration.

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

Per-domain directories were introduced in order to be able to
completely separate security labels for each domain (commit
f1f68ca3).  However when the domain
name is long (let's say a ridiculous 110 characters), we cannot
connect to the monitor socket because on length of UNIX socket address
is limited.  In order to get around this, let's shorten it in similar
fashion and in order to avoid conflicts, throw in an ID there as well.
Also save that into the status XML and load the old status XMLs
properly (to clean up after older domains).  That way we can change it
in the future.

The shortening can be seen in qemuxml2argv tests, for example in the
hugepages-pages2 case.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Similarly to VM startup always set the legacy affinity. Additionally we
don't need to report an explicit error since virProcessSetAffinity
reports them themselves.

Similarly to VM startup always set the legacy affinity. Additionally we
don't need to report an explicit error since virProcessSetAffinity
reports them themselves.

Calling qemuProcessStop without a job opens a way to race conditions
with qemuDomainObjExitMonitor called in another thread. A real world
example of such a race condition:

  - migration thread (A) calls qemuMigrationWaitForSpice
  - another thread (B) starts processing qemuDomainAbortJob API
  - thread B signals thread A via qemuDomainObjAbortAsyncJob
  - thread B enters monitor (qemuDomainObjEnterMonitor)
  - thread B calls qemuMonitorSend
  - thread A awakens and calls qemuProcessStop
  - thread A calls qemuMonitorClose and sets priv->mon to NULL
  - thread B calls qemuDomainObjExitMonitor with priv->mon == NULL
  => monitor stays ref'ed and locked

Depending on how lucky we are, the race may result in a memory leak or
it can even deadlock libvirtd's event loop if it tries to lock the
monitor to process an event received before qemuMonitorClose was called.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Stopping a domain without a job risks a race condition with another
thread which started a job a which does not expect anyone else to be
messing around with the same domain object.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Only a small portion of processGuestPanicEvent was enclosed within a
job, let's make sure we use the job for all operations to avoid race
conditions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

When destroying a domain we need to make sure we will be able to start a
job no matter what other operations are running or even stuck in a job.
This is done by killing the domain before starting the destroy job.

Let's introduce qemuProcessBeginStopJob which combines killing a domain
and starting a job in a single API which can be called everywhere we
need a job to stop a domain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuDomainHelperGetVcpus would correctly return an array of
virVcpuInfoPtr structs for online vcpus even for sparse topologies, but
the loop that fills the returned typed parameters would number the vcpus
incorrectly. Fortunately sparse topologies aren't supported yet.

VM startup and CPU hotplug always set the affinity regardless of cgroups
support. Use the same approach for the pinning API.

Both errors from the cgroups code and from the affinity code would be
overwritten by the API. Report the more specific error.

Now that the file migration doesn't require us to use 'dd' and other
legacy stuff for too old qemus we don't even have to calcuate the
offsets and other stuff.

Our existing virHashForEach method iterates through all items disregarding the
fact, that some of the iterators might have actually failed. Errors are usually
dispatched through an error element in opaque data which then causes the
original caller of virHashForEach to return -1. In that case, virHashForEach
could return as soon as one of the iterators fail. This patch changes the
iterator return type and adjusts all of its instances accordingly, so the
actual refactor of virHashForEach method can be dealt with later.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

For other objects we use the two functions rather than one with a bool.
Convert qemuSetImageCgroup to the same approach.