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

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

qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The caller is already aware that the params are missing and the
extractor is ignoring the missing ones so the parameter isn't necessary.

Extract information for all disks and update tray state and source only
for removable drives. Additionally store whether a drive is removable
and whether it has a tray.

It was only called for QEMUs without QEMU_CAPS_DEVICE,
which we no longer support.

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We had both and the only difference was that the latter also included
information about multifunction setting.  The problem with that was that
we couldn't use functions made for only one of the structs (e.g.
parsing).  To consolidate those two structs, use the one in virpci.h,
include that in domain_conf.h and add the multifunction member in it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Code was obsoleted by using -device.

QEMU introduced the query-gic-capabilities QMP command
with commit 4468d4e0f383: use the command, if available,
to probe available GIC capabilities.

The information obtained is stored in a virQEMUCaps
instance, and will be later used to fill in a
virDomainCaps instance.

Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

The event is emitted on ACPI OSPM Status Indication events.

ACPI standard documentation describes the method as:

This object is an optional control method that is invoked by OSPM to
indicate processing status to the platform. During device ejection,
device hot add, or other event processing, OSPM may need to perform
specific handshaking with the platform. OSPM may also need to indicate
to the platform its inability to complete a requested operation; for
example, when a user presses an ejection button for a device that is
currently in use or is otherwise currently incapable of being ejected.
In this case, the processing of the ACPI Eject Request notification by
OSPM fails. OSPM may indicate this failure to the platform through the
invocation of the _OST control method. As a result of the status
notification indicating ejection failure, the platform may take certain
action including reissuing the notification or perhaps turning on an
appropriate indicator light to signal the failure to the user.

Functions no longer required for attaching SCSI disks since
QEMU_CAPS_DEVICE is expected.

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

Migration enters "postcopy-active" state after QEMU switches to
post-copy and pauses guest CPUs. From libvirt's point of view this state
is similar to "completed" because we need to transfer guest execution to
the destination host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This attribute is used to extend secondary PCI bar and expose it to the
guest as 64bit memory.  It works like this: attribute vram is there to
set size of secondary PCI bar and guest sees it as 32bit memory,
attribute vram64 can extend this secondary PCI bar.  If both attributes
are used, guest sees two memory bars, both address the same memory, with
the difference that the 32bit bar can address only the first part of the
whole memory.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749Signed-off-by: NPavel Hrdina <phrdina@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>

The migration code now doesn't need it, so remove the macros and the
configure code that is detecting it.

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.

With the currently supported qemus we always migrate to file
descriptors so the old function is not required any more.

Additionally QEMU_MONITOR_MIGRATE_TO_FILE_TRANSFER_SIZE macro is now
unused.

The corresponding event in QEMU is called MIGRATION_PASS.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

memory_dirty_rate corresponds to dirty-pages-rate in QEMU and
memory_iteration is what QEMU reports in dirty-sync-count.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The enum will be called qemuMonitorMigrationStatus.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The structure actually contains migration statistics rather than just
the status as the name suggests. Renaming it as
qemuMonitorMigrationStats removes the confusion.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

A migration is in "setup" state after it was "inactive" and before it
becomes "active". Let's reflect this in our migration status enum.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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>

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>

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

Earlier virtType was of type int. After, introducing the enum VIR_DOMAIN_VIRT_NONE,
the type of virtType is modified to virDomainVirtType.

Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>

Few parts of the code looked at the current progress of and assumed that
a two phase blockjob is in the _READY state as soon as the progress
reached 100% (info.cur == info.end). In current versions of qemu this
assumption is invalid and qemu exposes a new flag 'ready' in the
query-block-jobs output that is set to true if the job is actually
finished.

This patch adds internal data handling for reading the 'ready' flag and
acting appropriately as long as the flag is present.

While this still doesn't fix the virsh client problem with two phase
block jobs and the --pivot option, it at least improves the error
message:

$ virsh blockcommit  --wait --verbose vm vda  --base vda[1] --active --pivot
Block commit: [100 %]error: failed to pivot job for disk vda
error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed

to

$ virsh blockcommit  --wait --verbose VM vda  --base vda[1] --active --pivot
Block commit: [100 %]error: failed to pivot job for disk vda
error: block copy still active: disk 'vda' not ready for pivot yet

If QEMU fails during incoming migration, the domain disappears including
a possibly useful error message read from QEMU log file. Let's remember
the error in virQEMUDriver so that Finish can report more than just "no
such domain".
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Even if QEMU supports migration events it doesn't send them by default.
We have to enable them by calling migrate-set-capabilities. Let's enable
migration events everytime we can and clear QEMU_CAPS_MIGRATION_EVENT in
case migrate-set-capabilities does not support events.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Thanks to Juan's work QEMU finally emits an event whenever migration
state changes.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Now that qemuMonitorGetAllBlockStatsInfo collects also wr_highest_offset
the whole function can be killed.

Instead of using qemuMonitorJSONDevGetBlockExtent (which I plan to
remove later) extract the data in place.

Additionally add a flag that will be set when the wr_highest_offset was
extracted correctly so that callers can act according to that.

The test case addition should help make sure that everything works.

QEMU_CAPS_SEAMLESS_MIGRATION capability says QEMU supports
SPICE_MIGRATE_COMPLETED event. Thus we can just drop all code which
polls query-spice and replace it with waiting for the event.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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