- 02 2月, 2018 1 次提交
-
-
由 Peter Krempa 提交于
In my first approach in 4b480d10 I overlooked the comment in qemuMigrationRunIncoming stating that during actual migration the qemuMigrationRunIncoming does not wait until the migration is complete but rather offloads that to the Finish phase of migration. This means that during actual migration qemuProcessRefreshState was called prior to qemu actually transferring the full state and thus the queries did not get the correct information. The approach worked only for restore, where we wait for the migration to finish during qemu startup. Fix the issue by calling qemuProcessRefreshState both from qemuProcessStart if there's no incomming migration and from qemuMigrationFinish so that the code actually works as expected.
-
- 19 1月, 2018 1 次提交
-
-
由 Jiri Denemark 提交于
When migrating a shutoff domain (i.e., offline migration), we have no statistics to report and thus jobInfo will be NULL in qemuMigrationFinish. Broken by me in v3.10.0-183-ge8784e78. https://bugzilla.redhat.com/show_bug.cgi?id=1536351Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 12 1月, 2018 1 次提交
-
-
由 Jiri Denemark 提交于
Libvirt 3.7.0 and earlier libvirt reported a migration job as completed immediately after QEMU finished sending migration data at which point migration was not really complete yet. Commit v3.7.0-29-g3f2d6d82 fixed this, but caused a regression in reporting statistics for completed jobs which started reporting the job as still running. This happened because the completed job statistics including the job status are copied from the running job before we finally mark it as completed. Let's make sure QEMU_DOMAIN_JOB_STATUS_COMPLETED is always set in the completed job info even when the job has not finished yet. https://bugzilla.redhat.com/show_bug.cgi?id=1523036Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 06 12月, 2017 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 03 11月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Jiri Denemark 提交于
The parameters used "migrate" prefix which is pretty redundant and qemuMonitorMigrationParams structure is our internal representation of QEMU migration parameters and it is supposed to use names which match QEMU names. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 26 10月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
QEMU identified a race condition between the device state serialization and the end of storage migration. Both QEMU and libvirt needs to be updated to fix this. Our migration work flow is modified so that after starting the migration we to wait for QEMU to enter "pre-switchover", "postcopy-active", or "completed" state. Once there, we cancel all block jobs as usual. But if QEMU is in "pre-switchover", we need to resume the migration afterwards and wait again for the real end (either "postcopy-active" or "completed" state). Old QEMU will just enter either "postcopy-active" or "completed" directly, which is still correctly handled even by new libvirt. The "pre-switchover" state will only be entered if QEMU supports it and the pause-before-switchover capability was enabled. Thus all combinations of libvirt and QEMU will work, but only new QEMU with new libvirt will avoid the race condition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This new capability enables a pause before device state serialization so that we can finish all block jobs without racing with the end of the migration. The pause is indicated by "pre-switchover" state. Once we're done QEMU enters "device" migration state. This patch just defines the new capability and QEMU migration states and their mapping to our job states. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 23 10月, 2017 7 次提交
-
-
由 Jiri Denemark 提交于
Instead of enumerating all states which need to be turned into QEMU_DOMAIN_JOB_STATUS_FAILED (and failing to add all of them), it's better to mention just the one which needs to be left alone. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Almost every failure in qemuMigrationRun while we are talking to QEMU monitor results in a jump to exit_monitor label. The only exception is removed by this patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The "ret" variable is used for storing the return value of a function and should not be used as a temporary variable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Merge cancel and cancelPostCopy sections with the generic error section, where we can easily decide whether canceling the ongoing migration is required. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Let cleanup only do things common to both failure and success paths and move error handling code inside the new "error" section. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Some code which was supposed to be executed only when migration succeeded was buried inside the cleanup code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
When adding a new job state it's useful to let the compiler complain about places where we need to think about what to do with the new state. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 20 10月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
All calls to qemuMonitorGetMigrationCapability in QEMU driver are replaced with qemuMigrationCapsGet. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 19 10月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
We need to send allowReboot in the migration cookie to ensure the same behavior of the virDomainSetLifecycleAction() API on the destination. Consider this scenario: 1. On the source the domain is started with: <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> 2. User calls an API to set "destroy" for <on_reboot>: <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> 3. The guest is migrated to a different host 4a. Without the allowReboot in the migration cookie the QEMU process on destination would be started with -no-reboot which would prevent using the virDomainSetLifecycleAction() API for the rest of the guest lifetime. 4b. With the allowReboot in the migration cookie the QEMU process on destination is started without -no-reboot like it was started on the source host and the virDomainSetLifecycleAction() API continues to work. The following patch adds a QEMU implementation of the virDomainSetLifecycleAction() API and that implementation disallows using the API if all actions are set to "destroy" because we add "-no-reboot" on the QEMU command line. Changing the lifecycle action is in this case pointless because the QEMU process is always terminated. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 17 10月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
When migration fails, QEMU may provide a description of the error in the reply to query-migrate QMP command. We can fetch this error and use it instead of the generic "unexpectedly failed" message. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 05 10月, 2017 2 次提交
-
-
由 Peter Krempa 提交于
Pass flags to the function rather than just whether we have incoming migration. This also enforces correct startup policy for USB devices when reverting from a snapshot.
-
由 Peter Krempa 提交于
qemuMigrationPrepareAny called multiple of the functions starting the qemu process for incoming migration by adding the flags explicitly. Extract them to a variable so that they can be easily used for other calls or changed in the future.
-
- 25 9月, 2017 1 次提交
-
-
由 Daniel P. Berrange 提交于
Seeing a log message saying 'flags=93' is ambiguous & confusing unless you happen to know that libvirt always prints flags as hex. Change our debug messages so that they always add a '0x' prefix when printing flags, and '0' prefix when printing mode. A few other misc places gain a '0x' prefix in error messages too. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 14 9月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
Drop all the monitor code necessary to do the downstream block jobs. Reviewed-by: NEric Blake <eblake@redhat.com>
-
- 07 9月, 2017 9 次提交
-
-
由 Nikolay Shirokovskiy 提交于
In case of real migration (not migrating to file on save, dump etc) migration info is not complete at time qemu finishes migration in normal (non postcopy) mode. We need to update disks stats, downtime info etc. Thus let's not expose this job status as completed. To archive this let's set status to 'qemu completed' after qemu reports migration is finished. It is not visible as complete job to clients. Cookie code on confirm phase will finally turn job into completed. As we don't need more things to do when migrating to file status is set to 'completed' as before in this case. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
When getting job info in case mirror does not reach ready phase fetch mirror stats from qemu. Otherwise mirror stats are already saved in current job. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Instead of checking stat.status let's set status to migrating as soon as migrate command is send (waiting for completion is a good place too). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Setting status to none has little value - getting job status will not return even elapsed time. After this patch getting job stats stays correct in a sence it will not fetch migration stats because it consults stats.status before doing the fetch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
qemuMigrationFetchJobStatus is rather inconvinient. Some of its callers don't need status to be updated, some don't need to update elapsed time right away. So let's update status or elapsed time in callers instead. This patch drops updating job status on getting job stats by client. This way we will not provide status 'completed' while it is not yet updated by migration routine. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
qemuMonitorGetMigrationStats will do it for us anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
This way we get stats only in one place. The former code waits for complete/postcopy status basically and don't need to mess with stats. The patch drops raising an error on stats updates failure. This does not make much sense anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Let's introduce QEMU_DOMAIN_JOB_STATUS_POSTCOPY state for job.current->status instead of checking job.current->stats.status. The latter can be changed when fetching migration statistics. Moving state function from the variable and leave only store function seems more managable. This patch removes all state checking usage of stats except for qemuDomainGetJobStatsInternal. This place will be handled separately. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
This patch simply switches code from using VIR_DOMAIN_JOB_* to introduced QEMU_DOMAIN_JOB_STATUS_*. Later this gives us freedom to introduce states for postcopy and mirroring phases. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 29 8月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
At some places we either already have synchronous job or we just released it. Also, some APIs might want to use this code without having to release their job. Anyway, the job acquire code is moved out to qemuDomainRemoveInactiveJob so that qemuDomainRemoveInactive does just what it promises. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 18 8月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Offline migration transfers only the domain definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449715Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 20 7月, 2017 1 次提交
-
-
由 Hao Peng 提交于
At present shared disks can be migrated with either readonly or cache=none. But cache=directsync should be safe for migration, because both cache=directsync and cache=none don't use the host page cache, and cache=direct write through qemu block layer cache. Signed-off-by: NPeng Hao <peng.hao2@zte.com.cn> Reviewed-by: NWang Yechao <wang.yechao255@zte.com.cn>
-
- 19 7月, 2017 1 次提交
-
-
由 Wang King 提交于
Should be followed with qemuDomainObjExitMonitor only if qemuDomainObjEnterMonitorAsync returns 0. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 6月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
While qemuProcessIncomingDefNew takes an fd argument and stores it in qemuProcessIncomingDef structure, the caller is still responsible for closing the file descriptor. Introduced by commit v1.2.21-140-ge7c6f457. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 14 6月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Most places which want to check ABI stability for an active domain need to call this API rather than the original qemuDomainDefCheckABIStability. The only exception is in snapshots where we need to decide what to do depending on the saved image data. https://bugzilla.redhat.com/show_bug.cgi?id=1460952Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 13 6月, 2017 1 次提交
-
-
由 Marc Hartmayer 提交于
Use ATTRIBUTE_FALLTHROUGH, introduced by commit 5d84f596, instead of comments to indicate that the fall through is an intentional behavior. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
- 07 6月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
If QEMU is new enough and we have the live updated CPU definition in either save or migration cookie, we can use it to enforce ABI. The original guest CPU from domain XML will be stored in private data. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Since the domain XML send during migration uses the original guest CPU definition but we still want the destination to enforce ABI if it is new enough, we send the live updated CPU definition in a migration cookie. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-