- 09 1月, 2016 3 次提交
-
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
The enum will be called qemuMonitorMigrationStatus. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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>
-
- 08 1月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
My commit 674afcb0 moved computing the default listen address from qemuMigrationPrepareAny to qemuMigrationPrepareIncoming. However, I didn't notice listenAddress was later passed to qemuMigrationStartNBDServer. Thus, it would be called with the original value of listenAddress (NULL). Let's add the updated listen address to qemuProcessIncomingDef and use it when starting NBD servers. Reported-by: NMichael Chapman <mike@very.puzzling.org> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 1月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 1月, 2016 1 次提交
-
-
由 Michael Chapman 提交于
Valgrind complained: ==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 188 of 996 ==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593) ==18990== by 0x5292E9B: virAllocN (viralloc.c:191) ==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012) ==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413) ==18990== by 0x222228CE: qemuMigrationPrepareAny (qemu_migration.c:3463) ==18990== by 0x22224121: qemuMigrationPrepareDirect (qemu_migration.c:3865) ==18990== by 0x22251C25: qemuDomainMigratePrepare3Params (qemu_driver.c:12414) ==18990== by 0x5389EE0: virDomainMigratePrepare3Params (libvirt-domain.c:5107) ==18990== by 0x1278DB: remoteDispatchDomainMigratePrepare3ParamsHelper (remote.c:5425) ==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) ==18990== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156) ==18990== ==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 189 of 996 ==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593) ==18990== by 0x5292E9B: virAllocN (viralloc.c:191) ==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012) ==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413) ==18990== by 0x222249D2: qemuMigrationRun (qemu_migration.c:4395) ==18990== by 0x22226365: doNativeMigrate (qemu_migration.c:4693) ==18990== by 0x22228E45: qemuMigrationPerform (qemu_migration.c:5553) ==18990== by 0x2225144B: qemuDomainMigratePerform3Params (qemu_driver.c:12621) ==18990== by 0x539F5D8: virDomainMigratePerform3Params (libvirt-domain.c:5206) ==18990== by 0x127305: remoteDispatchDomainMigratePerform3ParamsHelper (remote.c:5557) ==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) If we're replacing the NBD data, it's simplest to free the old object (including the disk list) and allocate a new one. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
- 26 11月, 2015 2 次提交
-
-
由 Daniel P. Berrange 提交于
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>
-
由 Daniel P. Berrange 提交于
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>
-
- 25 11月, 2015 4 次提交
-
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 19 11月, 2015 3 次提交
-
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Move the code from qemuMigrationFinish into a dedicated function. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 10 11月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
Since we require QEMU 0.12.0, we can assume that QEMU supports all of the fd, tcp, unix and exec migration protocols. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 05 11月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
The code reported that a migration flag is unsupported but didn't jump to the error label. Probably an oversight in commit f88af9dc that introduced the flag checking.
-
由 Peter Krempa 提交于
Since the flag was not enabled when 'eating' the migration cookie, libvirt reported a bogus error when memory hotplug was enabled: unsupported migration cookie feature memory-hotplug The error was ignored though due to a bug in the code so it slipped through testing. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1278404
-
- 27 10月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
In commit f41be296, we moved vm->persistent check into qemuDomainRemoveInactive, but we didn't change the vm->persistent before call qemuDomainRemoveInactive in some place before and just call it to remove the inactive vm. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 16 10月, 2015 1 次提交
-
-
由 Shivaprasad G Bhat 提交于
Tunnelled migration can hang if the destination qemu exits despite all the ABI checks. This happens whenever the destination qemu exits before the complete transfer is noticed by source qemu. The savevm state checks at runtime can fail at destination and cause qemu to error out. The source qemu cant notice it as the EPIPE is not propogated to it. The qemuMigrationIOFunc() notices the stream being broken from virStreamSend() and it cleans up the stream alone. The qemuMigrationWaitForCompletion() would never get to 100% transfer completion. The qemuMigrationWaitForCompletion() never breaks out as well since the ssh connection to destination is healthy, and the source qemu also thinks the migration is ongoing as the Fd to which it transfers, is never closed or broken. So, the migration will hang forever. Even Ctrl-C on the virsh migrate wouldn't be honoured. Close the source side FD when there is an error in the stream. That way, the source qemu updates itself and qemuMigrationWaitForCompletion() notices the failure. Close the FD for all kinds of errors to be sure. The error message is not copied for EPIPE so that the destination error is copied instead later. Note: Reproducible with repeated migrations between Power hosts running in different subcores-per-core modes. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
- 07 10月, 2015 4 次提交
-
-
由 Peter Krempa 提交于
qemuMigrationIsAllowed would disallow offline migration if the VM contained host devices or memory modules. Since during offline migration we don't transfer any state we can safely migrate VMs with such configuration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1265049
-
由 Peter Krempa 提交于
Use the migration @flags for checking various migration aspects rather than picking them out as booleans. Document the new semantics in the function header.
-
由 Peter Krempa 提交于
Now that qemuMigrationIsAllowed is always called with @vm, we can drop the @def argument and simplify the control flow. Additionally the comment is invalid so drop it.
-
由 Peter Krempa 提交于
Extract the hostdev check from qemuMigrationIsAllowed into a separate function since that is the only part that needs to be done in the v2 migration protocol prepare phase on the destination. All other checks were added when the v3 protocol existed so they don't need to be extracted. This change will allow to drop the @def argument for qemuMigrationIsAllowed and further simplify the function.
-
- 06 10月, 2015 5 次提交
-
-
由 Jiri Denemark 提交于
Even though QEMU on the source host reports completed migration and thus we move to the Finish phase, QEMU on the destination host may still be processing migration data. Thus before we can start guest CPUs on the destination, we have to wait for a completed migration event. https://bugzilla.redhat.com/show_bug.cgi?id=1265902Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
With new QEMU which supports migration events, qemuMigrationCheckJobStatus needs to explicitly query QEMU for migration statistics once migration is completed to make sure the caller sees up-to-date statistics with both old and new QEMU. However, some callers are not interested in the statistics at all and once we start waiting for a completed migration on the destination host too, checking the statistics would even fail. Let's push the decision whether to update the statistics or not to the caller. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function already has two bool parameters and we will need to add a new one. Let's switch to flags to make the callers readable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The destination host gets detailed statistics about the current migration form the source host via migration cookie and copies them to the domain object so that they can be queried using virDomainGetJobStats. However, we should only copy statistics to the domain object when migration finished successfully. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Even if we are migrating a domain with VIR_MIGRATE_PAUSED flag set, we should still update the total time of the migration. Updating downtime doesn't hurt either, even though we don't actually start guest CPUs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 24 9月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
So far we have the following pattern occurring over and over again: if (!vm->persistent) qemuDomainRemoveInactive(driver, vm); It's safe to put the check into the function and save some LoC. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 22 9月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
Add a new parser flag that will mark code paths that parse XML files wich will not be used with existing VM state so that post parse callbacks can possibly do ABI incompatible changes if needed.
-
由 Peter Krempa 提交于
Add a simple helper so that the code doesn't have to rewrite the same condition multiple times.
-
- 18 9月, 2015 8 次提交
-
-
由 Jiri Denemark 提交于
When persistently migrating a domain to a destination host where the same domain already exists (i.e., it is persistent and shutdown at the destination), we would happily throw away the original persistent definition without properly freeing it. And when updating the definition fails for some reason we don't properly revert to the original state leaving the domain broken. In addition to fixing these issues, the patch also makes sure the domain definition parsed from a migration cookie is either used or freed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
For quite a long time we don't need to postpone queueing events until the end of the function since we no longer have the big driver lock. Let's make the code of qemuMigrationFinish simpler by queuing events at the time we generate them. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Every single call to qemuDomainEventQueue() uses the following pattern: if (event) qemuDomainEventQueue(driver, event); Let's move the check for valid event to qemuDomainEventQueue and simplify all callers. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Finish is the final state in v2 of our migration protocol. If something fails, we have no option to abort the migration and resume the original domain. Non fatal errors (such as failure to start guest CPUs or make the domain persistent) has to be treated as success. Keeping the domain running while reporting the failure was just asking for trouble. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Whenever something fails during incoming migration in Finish phase before we started guest CPUs, we need to kill the domain in addition to reporting the failure. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When we save status XML at the point during migration where we have already started the domain on destination, we can't really go back and abort migration. Thus the only thing we can do is to log a warning and report success. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Offline migration is quite special because we don't really need to do anything but make the domain persistent. Let's do it separately from normal migration to avoid cluttering the code with !(flags & VIR_MIGRATE_OFFLINE). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Separate code which makes incoming domain persistent into qemuMigrationPersist. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-