- 08 11月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Since 86d90b3a (yes, my patch; again) we are supporting NBD storage migration. However, on error recovery path we got the steps reversed. The correct order is: return NBD port to the virPortAllocator and then either unlock the vm or remove it from the driver. Not vice versa. ==11192== Invalid write of size 4 ==11192== at 0x11488559: qemuMigrationPrepareAny (qemu_migration.c:2459) ==11192== by 0x11488EA6: qemuMigrationPrepareDirect (qemu_migration.c:2652) ==11192== by 0x114D1509: qemuDomainMigratePrepare3Params (qemu_driver.c:10332) ==11192== by 0x519075D: virDomainMigratePrepare3Params (libvirt.c:7290) ==11192== by 0x1502DA: remoteDispatchDomainMigratePrepare3Params (remote.c:4798) ==11192== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==11192== by 0x5212127: virNetServerProgramDispatchCall (virnetserverprogram.c:435) ==11192== by 0x5211C86: virNetServerProgramDispatch (virnetserverprogram.c:305) ==11192== by 0x520A8FD: virNetServerProcessMsg (virnetserver.c:165) ==11192== by 0x520A9E1: virNetServerHandleJob (virnetserver.c:186) ==11192== by 0x50DA78F: virThreadPoolWorker (virthreadpool.c:144) ==11192== by 0x50DA11C: virThreadHelper (virthreadpthread.c:161) ==11192== Address 0x1368baa0 is 576 bytes inside a block of size 688 free'd ==11192== at 0x4A07F5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11192== by 0x5079A2F: virFree (viralloc.c:580) ==11192== by 0x11456C34: qemuDomainObjPrivateFree (qemu_domain.c:267) ==11192== by 0x50F41B4: virDomainObjDispose (domain_conf.c:2034) ==11192== by 0x50C2991: virObjectUnref (virobject.c:262) ==11192== by 0x50F4CFC: virDomainObjListRemove (domain_conf.c:2361) ==11192== by 0x1145C125: qemuDomainRemoveInactive (qemu_domain.c:2087) ==11192== by 0x11488520: qemuMigrationPrepareAny (qemu_migration.c:2456) ==11192== by 0x11488EA6: qemuMigrationPrepareDirect (qemu_migration.c:2652) ==11192== by 0x114D1509: qemuDomainMigratePrepare3Params (qemu_driver.c:10332) ==11192== by 0x519075D: virDomainMigratePrepare3Params (libvirt.c:7290) ==11192== by 0x1502DA: remoteDispatchDomainMigratePrepare3Params (remote.c:4798) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 07 11月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
So far we are checking if qemu supports 'nbd-server-start'. This, however, makes no sense on the source as nbd-server-* is used on the destination. On the source the 'drive-mirror' is used instead. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 06 11月, 2013 1 次提交
-
-
由 Zeng Junliang 提交于
If there's a migration cancelled, the bitmap of migration port should be cleaned up too. Signed-off-by: NZeng Junliang <zengjunliang@huawei.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 01 11月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
Instead of using a port from the remote display range. https://bugzilla.redhat.com/show_bug.cgi?id=1025699
-
- 29 10月, 2013 1 次提交
-
-
由 Michael Chapman 提交于
When adding an automatically allocated port to a well-formed migration URI, keep it well-formed: tcp://1.2.3.4/ -> tcp://1.2.3.4/:12345 # wrong tcp://1.2.3.4/ -> tcp://1.2.3.4:12345/ # fixed tcp://1.2.3.4 -> tcp://1.2.3.4:12345 # still works tcp:1.2.3.4 -> tcp:1.2.3.4:12345 # still works (old syntax) Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
- 18 10月, 2013 1 次提交
-
-
由 Wang Yufei 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1019053 When we migrate vms concurrently, there's a chance that libvirtd on destination assigns the same port for different migrations, which will lead to migration failure during prepare phase on destination. So we use virPortAllocator here to solve the problem. Signed-off-by: NWang Yufei <james.wangyufei@huawei.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 11 10月, 2013 3 次提交
-
-
由 Michal Privoznik 提交于
After my patches, some functions gained one more argument (@listenAddress) which wasn't included in debug printing of arguments they were called with. Functions in question are: qemuMigrationPrepareDirect and qemuMigrationPerform. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=994364 Whenever we check for ABI stability, we have new xml (e.g. provided by user, or obtained from snapshot, whatever) which we compare to old xml and see if ABI won't break. However, if the new xml was produced via virDomainGetXMLDesc(..., VIR_DOMAIN_XML_MIGRATABLE) it lacks some devices, e.g. 'pci-root' controller. Hence, the ABI stability check fails even though it is stable. Moreover, we can't simply fix virDomainDefCheckABIStability because removing the correct devices is task for the driver. For instance, qemu driver wants to remove the usb controller too, while LXC driver doesn't. That's why we need special qemu wrapper over virDomainDefCheckABIStability which removes the correct devices from domain XML, produces MIGRATABLE xml and calls the check ABI stability function. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 9月, 2013 1 次提交
-
-
由 Martin Kletzander 提交于
Since the wait is done during migration (still inside QEMU_ASYNC_JOB_MIGRATION_OUT), the code should enter the monitor as such in order to prohibit all other jobs from interfering in the meantime. This patch fixes bug #1009886 in which qemuDomainGetBlockInfo was waiting on the monitor condition and after GetSpiceMigrationStatus mangled its internal data, the daemon crashed. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1009886
-
- 17 9月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
qemuMigrationEatCookie has flags to control if these should be parsed, but it does not fill mig->flags. These cookies might get leaked if these flags are not set by qemuMigrationBakeCookie. 42 (32 direct, 10 indirect) bytes in 1 blocks are definitely lost in loss record 361 of 662 ==123== by 0x1BA33FCA: qemuMigrationEatCookie (qemu_migration.c:678) ==123== by 0x1BA34A1E: qemuMigrationRun (qemu_migration.c:3108) ==123== by 0x1BA3622B: doNativeMigrate (qemu_migration.c:3343) ==123== by 0x1BA3B408: qemuMigrationPerform (qemu_migration.c:4138)
-
- 10 9月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Osier Yang pointed out that ever since commit 31cb030a, the signature of qemuDomainObjEndJob was changed to return a bool. While comparison against 0 or > 0 still gives the right results, it looks fishy; we also had one place that was comparing < 0 which is effectively dead code. * src/qemu/qemu_migration.c (qemuMigrationPrepareAny): Fix dead code bug. (qemuMigrationBegin): Use more canonical form of bool check. * src/qemu/qemu_driver.c (qemuAutostartDomain) (qemuDomainCreateXML, qemuDomainSuspend, qemuDomainResume) (qemuDomainShutdownFlags, qemuDomainReboot, qemuDomainReset) (qemuDomainDestroyFlags, qemuDomainSetMemoryFlags) (qemuDomainSetMemoryStatsPeriod, qemuDomainInjectNMI) (qemuDomainSendKey, qemuDomainGetInfo, qemuDomainScreenshot) (qemuDomainSetVcpusFlags, qemuDomainGetVcpusFlags) (qemuDomainRestoreFlags, qemuDomainGetXMLDesc) (qemuDomainCreateWithFlags, qemuDomainAttachDeviceFlags) (qemuDomainUpdateDeviceFlags, qemuDomainDetachDeviceFlags) (qemuDomainBlockResize, qemuDomainBlockStats) (qemuDomainBlockStatsFlags, qemuDomainMemoryStats) (qemuDomainMemoryPeek, qemuDomainGetBlockInfo) (qemuDomainAbortJob, qemuDomainMigrateSetMaxDowntime) (qemuDomainMigrateGetCompressionCache) (qemuDomainMigrateSetCompressionCache) (qemuDomainMigrateSetMaxSpeed) (qemuDomainSnapshotCreateActiveInternal) (qemuDomainRevertToSnapshot, qemuDomainSnapshotDelete) (qemuDomainQemuMonitorCommand, qemuDomainQemuAttach) (qemuDomainBlockJobImpl, qemuDomainBlockCopy) (qemuDomainBlockCommit, qemuDomainOpenGraphics) (qemuDomainGetBlockIoTune, qemuDomainGetDiskErrors) (qemuDomainPMSuspendForDuration, qemuDomainPMWakeup) (qemuDomainQemuAgentCommand, qemuDomainFSTrim): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 04 9月, 2013 1 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=999352 Since commit v1.0.5-56-g449e6b1b (Pull parsing of migration xml up into QEMU driver APIs) any attempt to rename a domain during migration fails with the following error message: internal error Incoming cookie data had unexpected name DOM vs DOM2 This is because migration cookies always use the original domain name and the mentioned commit failed to propagate the name back to qemuMigrationPrepareAny.
-
- 06 8月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=979477 Since 1.0.3 we are using the new way to copy non shared storage during migration (the NBD way). However, whether the new or old way is used is not controllable by user but unconditionally turned on if both sides of migration support it. Moreover, the implementation is not complete: the combination for VIR_MIGRATE_TUNNELLED flag is missing (as we need to open new port on the destination) in which case we just error out. This is a deadly combination: not letting users choose their destiny and erroring out. We should not do that but VIR_WARN and turn the NBD off instead.
-
- 22 7月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
Convert the remaining methods in vircgroup.c to report errors instead of returning errno values. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 7月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 11 7月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
Convert the type of loop iterators named 'i', 'j', k', 'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or 'unsigned int', also santizing 'ii', 'jj', 'kk' to use the normal 'i', 'j', 'k' naming Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 10 7月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Remove assignment of the string freed by virURIFree to hostname, since it's not used anywhere. Double free introduced by ddf8ad82, useless code introduced by f03dcc5d. https://bugzilla.redhat.com/show_bug.cgi?id=977961
-
由 Michal Privoznik 提交于
-
- 08 7月, 2013 2 次提交
-
-
由 Jiri Denemark 提交于
Whenever virPortAllocatorRelease is called with port == 0, it complains that the port is not in an allowed range, which is expectable as the port was never allocated. Let's make virPortAllocatorRelease ignore 0 ports in a similar way free() ignores NULL pointers.
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=981139 If a domain is paused before migration starts, we need to tell that to the destination libvirtd to prevent it from resuming the domain at the end of migration. This regression was introduced by commit 5379bb0f.
-
- 03 7月, 2013 1 次提交
-
-
由 Martin Kletzander 提交于
Since commit 23e8b5d8, the code is refactored in a way that supports domains with multiple graphics elements and commit 37b41520 allows starting such domains. However none of those commits take migration into account. Even though qemu doesn't support relocation for anything else than SPICE and for no more than one graphics, there is no reason to hardcode one graphics into this part of the code as well.
-
- 25 6月, 2013 5 次提交
-
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
- 18 6月, 2013 4 次提交
-
-
由 Peter Krempa 提交于
This flag is meant for errors happening on the source of the migration and isn't used on the destination. To allow better migration compatibility, don't propagate it to the destination.
-
由 Peter Krempa 提交于
Paolo Bonzini pointed out that it's actually possible to migrate a qemu instance that was paused due to I/O error and it will be able to work on the destination if the storage is accessible. This patch introduces flag VIR_MIGRATE_ABORT_ON_ERROR that cancels the migration in case an I/O error happens while it's being performed and allows migration without this flag. This flag can be possibly used for other error reasons that may be introduced in the future.
-
由 Jiri Denemark 提交于
-
由 Michal Privoznik 提交于
Currently, we wait for SPICE to migrate in the very same loop where we wait for qemu to migrate. This has a disadvantage of slowing seamless migration down. One one hand, we should not kill the domain until all SPICE data has been migrated. On the other hand, there is no need to wait in the very same loop and hence slowing down 'cont' on the destination. For instance, if users are watching a movie, they can experience the movie to be stopped for a couple of seconds, as processors are not running nor on src nor on dst as libvirt waits for SPICE to migrate. We should move the waiting phase to migration CONFIRM phase.
-
- 11 6月, 2013 3 次提交
-
-
由 Peter Krempa 提交于
Such machine can't be successuflly migrated unles the I/O error has recovered and might lead to data corruption. Forbid this kind of migration.
-
由 Peter Krempa 提交于
During a live migration the guest may receive a disk access I/O error. In this state the guest is unable to continue running on a remote host after migration as some state may be present in the kernel and not migrated. With this patch, the migration is canceled in such case so it can either continue on the source if the I/O issues are recovered or has to be destroyed anyways.
-
由 Jiri Denemark 提交于
Avoid leaking virDomainDef if Prepare phase fails before it gets to qemuMigrationPrepareAny.
-
- 07 6月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Since we have the new internal API to check for wildcard address, we can use it instead of parsing and formatting.
-
- 06 6月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Found with 'git grep "= 1"'.
-
由 Michal Privoznik 提交于
Currently, a listen address for a SPICE server can be specified. Later, when the domain is migrated, we need to relocate the graphics which involves telling new destination to the SPICE server. However, we can't just assume the listen address is the new location, because the listen address can be ANYCAST (0.0.0.0 for IPv4, :: for IPv6). In which case, we want to pass the remote hostname. But there are some troubles with ANYCAST. In both IPv4 and IPv6 it has many ways for specifying such address. For instance, in IPv4: 0, 0.0, 0.0.0, 0.0.0.0. The number of variations gets bigger in IPv6 world. Hence, in order to check for ANYCAST address sanely, we should take the provided listen address, parse it and format back in it's full form. Which is exactly what this patch does.
-
- 31 5月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
A literal IPv6 must be escaped, otherwise migration fails with: unable to execute QEMU command 'drive-mirror': address resolution failed for f0::0d:5901: Servname not supported for ai_socktype since QEMU treats everything after the first ':' as the port.
-
- 30 5月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
Since as the code indicates it doesn't work yet, so let's be explicit about it.
-
由 Cole Robinson 提交于
By actually showing the Open() error to the user
-