aboutsummaryrefslogtreecommitdiff
path: root/migration
AgeCommit message (Collapse)AuthorFilesLines
2016-10-30COLO: Synchronize PVM's state to SVM periodicallyzhanghailiang1-0/+12
Do checkpoint periodically, the default interval is 200ms. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: Add checkpoint-delay parameter for migrate-set-parameterszhanghailiang1-0/+16
Add checkpoint-delay parameter for migrate-set-parameters, so that we can control the checkpoint frequency when COLO is in periodic mode. Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: Load VMState into QIOChannelBuffer before restore itzhanghailiang1-2/+65
We should not destroy the state of SVM (Secondary VM) until we receive the complete data of PVM's state, in case the primary fails in the process of sending the state, so we cache the VM's state in secondary side before load it into SVM. Besides, we should call qemu_system_reset() before load VM state, which can ensure the data is intact. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: Send PVM state to secondary side when do checkpointzhanghailiang2-17/+105
VM checkpointing is to synchronize the state of PVM to SVM, just like migration does, we re-use save helpers to achieve migrating PVM's state to Secondary side. COLO need to cache the data of VM's state in the secondary side before synchronize it to SVM. COLO need the size of the data to determine how much data should be read in the secondary side. So here, we can get the size of the data by saving it into I/O channel before send it to the secondary side. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: Introduce checkpointing protocolzhanghailiang2-2/+201
We need communications protocol of user-defined to control the checkpointing process. The new checkpointing request is started by Primary VM, and the interactive process like below: Checkpoint synchronizing points: Primary Secondary initial work 'checkpoint-ready' <-------------------- @ 'checkpoint-request' @ --------------------> Suspend (Only in hybrid mode) 'checkpoint-reply' <-------------------- @ Suspend&Save state 'vmstate-send' @ --------------------> Send state Receive state 'vmstate-received' <-------------------- @ Release packets Load state 'vmstate-load' <-------------------- @ Resume Resume (Only in hybrid mode) Start Comparing (Only in hybrid mode) NOTE: 1) '@' who sends the message 2) Every sync-point is synchronized by two sides with only one handshake(single direction) for low-latency. If more strict synchronization is required, a opposite direction sync-point should be added. 3) Since sync-points are single direction, the remote side may go forward a lot when this side just receives the sync-point. 4) For now, we only support 'periodic' checkpoint, for which the Secondary VM is not running, later we will support 'hybrid' mode. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: Establish a new communicating path for COLOzhanghailiang1-0/+28
This new communication path will be used for returning messages from Secondary side to Primary side. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30migration: Switch to COLO process after finishing loadvmzhanghailiang3-0/+43
Switch from normal migration loadvm process into COLO checkpoint process if COLO mode is enabled. We add three new members to struct MigrationIncomingState, 'have_colo_incoming_thread' and 'colo_incoming_thread' record the COLO related thread for secondary VM, 'migration_incoming_co' records the original migration incoming coroutine. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30migration: Enter into COLO mode after migration if COLO is enabledzhanghailiang3-5/+65
Add a new migration state: MIGRATION_STATUS_COLO. Migration source side enters this state after the first live migration successfully finished if COLO is enabled by command 'migrate_set_capability x-colo on'. We reuse migration thread, so the process of checkpointing will be handled in migration thread. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30COLO: migrate COLO related info to secondary nodezhanghailiang2-0/+52
We can determine whether or not VM in destination should go into COLO mode by referring to the info that was migrated. We skip this section if COLO is not enabled (i.e. migrate_set_capability colo off), so that, It doesn't break compatibility with migration no matter whether users configure the --enable-colo/disable-colo on the source/destination side or not; Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-30migration: Introduce capability 'x-colo' to migrationzhanghailiang3-0/+38
We add helper function colo_supported() to indicate whether colo is supported or not, with which we use to control whether or not showing 'x-colo' string to users, they can use qmp command 'query-migrate-capabilities' or hmp command 'info migrate_capabilities' to learn if colo is supported. The default value for COLO (COarse-Grain LOck Stepping) is disabled. Cc: Juan Quintela <quintela@redhat.com> Cc: Amit Shah <amit.shah@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-28Merge remote-tracking branch 'remotes/berrange/tags/pull-qio-2016-10-27-1' ↵Peter Maydell6-0/+15
into staging Merge qio 2016/10/27 v1 # gpg: Signature made Thu 27 Oct 2016 13:54:03 BST # gpg: using RSA key 0xBE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" # gpg: aka "Daniel P. Berrange <berrange@redhat.com>" # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/pull-qio-2016-10-27-1: main: set names for main loop sources created vnc: set name for all I/O channels created migration: set name for all I/O channels created char: set name for all I/O channels created nbd: set name for all I/O channels created io: add ability to set a name for IO channels io: Add a QIOChannelSocket cleanup test io: set LISTEN flag explicitly for listen sockets io: Introduce a qio_channel_set_feature() helper io: Use qio_channel_has_feature() where applicable io: Fix double shift usages on QIOChannel features Conflicts: qemu-char.c Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-27migration: set name for all I/O channels createdDaniel P. Berrange6-0/+15
Ensure that all I/O channels created for migration are given names to distinguish their respective roles. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-24migration/savevm.c: migrate non-default page sizePeter Maydell1-0/+49
Add a subsection to vmstate_configuration which is present only if the guest is using a target page size which is different from the default. This allows us to helpfully diagnose attempts to migrate between machines which are using different target page sizes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-10-24migration: Remove static allocation of xzblre cache bufferVijaya Kumar K1-1/+3
Allocate xzblre zero page cache buffer dynamically. Remove dependency on TARGET_PAGE_SIZE to make run-time page size detection for arm platforms. Signed-off-by: Vijaya Kumar K <vijayak@cavium.com> Message-id: 1465808915-4887-2-git-send-email-vijayak@caviumnetworks.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-13migrate: move max-bandwidth and downtime-limit to migrate_set_parameterAshijeet Acharya1-33/+50
Mark the old commands 'migrate_set_speed' and 'migrate_set_downtime' as deprecated. Move max-bandwidth and downtime-limit into migrate-set-parameters for setting maximum migration speed and expected downtime limit parameters respectively. Change downtime units to milliseconds (only for new-command) and set its upper bound limit to 2000 seconds. Update the query part in both hmp and qmp qemu control interfaces. Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration: Fix seg with missing portDr. David Alan Gilbert1-4/+12
The command : migrate tcp:localhost: currently segs; fix it so it now says: error parsing address 'localhost:' and the same for -incoming. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration/postcopy: Explicitly disallow huge pagesDr. David Alan Gilbert1-0/+24
At the moment postcopy will fail as soon as qemu tries to register userfault on the RAMBlock pages that are backed by hugepages. However, the kernel is going to get userfault support for hugepage at some point, and we've not got the rest of the QEMU code to support it yet, so fail neatly with an error like: Postcopy doesn't support hugetlbfs yet (/objects/mem1) Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13Postcopy vs xbzrle: Don't send xbzrle pages once in postcopy [for 2.8]Dr. David Alan Gilbert1-1/+3
xbzrle relies on reading pages that have already been sent to the destination and then applying the modifications; we can't do that in postcopy because the destination may well have modified the page already or the page has been discarded. I already didn't allow reception of xbzrle pages, but I forgot to add the test to stop them being sent. Enabling both xbzrle and postcopy can make some sense; if you think that your migration might finish if you have xbzrle, then when it doesn't complete you flick over to postcopy and stop xbzrle'ing. This corresponds to RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1368422 Symptom is: Unknown combination of migration flags: 0x60 (postcopy mode) (either 0x60 or 0x40) Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migrate: Fix bounds check for migration parameters in migration.cAshijeet Acharya1-0/+2
This patch fixes the out-of-bounds check of migration parameters in qmp_migrate_set_parameters() for cpu-throttle-initial and cpu-throttle-increment by adding a return statement for both as they were broken since their introduction in 2.5 via commit 1626fee. Due to the missing return statements, parameters were getting set to out-of-bounds values despite the error. Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migrate: Use boxed qapi for migrate-set-parametersEric Blake1-38/+27
Now that QAPI makes it easy to pass a struct around, we don't have to declare as many parameters or local variables. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migrate: Share common MigrationParameters structEric Blake1-0/+7
It is rather verbose, and slightly error-prone, to repeat the same set of parameters for input (migrate-set-parameters) as for output (query-migrate-parameters), where the only difference is whether the members are optional. We can just document that the optional members will always be present on output, and then share a common struct between both commands. The next patch can then reduce the amount of code needed on input. Also, we made a mistake in qemu 2.7 of returning an empty string during 'query-migrate-parameters' when there is no TLS, rather than omitting TLS details entirely. Technically, this change risks breaking any 2.7 client that is hard-coded to expect the parameter's existence; on the other hand, clients that are portable to 2.6 already must be prepared for those members to not be present. And this gets rid of yet one more place where the QMP output visitor is silently converting a NULL string into "" (which is a hack I ultimately want to kill off). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration/rdma: Don't flag an error when we've been told about oneDr. David Alan Gilbert1-1/+5
If the other side tells us there's been an error and we fail the migration, we don't need to signal that failure to the other side because it already knew. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael R. Hines <michael@hinespot.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration: Make failed migration load set file errorDr. David Alan Gilbert1-7/+12
If an error occurs in a section load, set the file error flag so that the transport can get notified to do a cleanup. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael R. Hines <michael@hinespot.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration/rdma: Pass qemu_file errors across linkDr. David Alan Gilbert1-0/+3
If we fail for some reason (e.g. a mismatched RAMBlock) and it's set the qemu_file error flag, pass that error back to the peer so it can clean up rather than waiting for some higher level progress. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael R. Hines <michael@hinespot.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration: Report values for comparisonsDr. David Alan Gilbert1-0/+8
Report the values when a comparison fails; together with the previous patch that prints the device and field names this should give a good idea of why loading the migration failed. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-10-13migration: report an error giving the failed fieldDr. David Alan Gilbert1-0/+2
When a field fails to load (typically due to a limit check, or a call to a get/put) report the device and field to give an indication of the cause. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2016-09-27migration: sync all address spacesPaolo Bonzini1-1/+1
Migrating a VM during reboot sometimes results in differences between the source and destination in the SMRAM area. This is because migration_bitmap_sync() only fetches from KVM the dirty log of address_space_memory. SMRAM memory slots are ignored and the modifications to SMRAM are not sent to the destination. Reported-by: He Rongguang <herongguang.he@huawei.com> Reviewed-by: He Rongguang <herongguang.he@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-13cutils: Export only buffer_is_zeroRichard Henderson2-5/+2
Since the two users don't make use of the returned offset, beyond ensuring that the entire buffer is zero, consider the can_use_buffer_find_nonzero_offset and buffer_find_nonzero_offset functions internal. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Richard Henderson <rth@twiddle.net> Message-Id: <1472496380-19706-4-git-send-email-rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-08-12trace-events: fix first line comment in trace-eventsLaurent Vivier1-1/+1
Documentation is docs/tracing.txt instead of docs/trace-events.txt. find . -name trace-events -exec \ sed -i "s?See docs/trace-events.txt for syntax documentation.?See docs/tracing.txt for syntax documentation.?" \ {} \; Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-id: 1470669081-17860-1-git-send-email-lvivier@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-08-11migration/socket: fix typo in file headerCao jin1-1/+3
Code of inet socket & unix socket is merged together. Also add some newlines, make code block well separated. Cc: Daniel P. Berrange <berrange@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: Amit Shah <amit.shah@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Message-Id: <1469696074-12744-4-git-send-email-caoj.fnst@cn.fujitsu.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-08-11migration: fix live migration failure with compressionLiang Li1-0/+1
Because of commit 11808bb0c422, which remove some condition checks of 'f->ops->writev_buffer', 'qemu_put_qemu_file' should be enhanced to clear the 'f_src->iovcnt', or 'f_src->iovcnt' may exceed the MAX_IOV_SIZE which will break live migration. This should be fixed. Signed-off-by: Liang Li <liang.z.li@intel.com> Reported-by: Jinshi Zhang <jinshi.c.zhang@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1470702146-24399-1-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-08-11migration: mmap error check fixEvgeny Yakovlev1-1/+2
mmap man page: "On success, mmap() returns a pointer to the mapped area. On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error." The check in postcopy_get_tmp_page is definitely wrong and should be fixed. Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Amit Shah <amit.shah@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> CC: Juan Quintela <quintela@redhat.com> CC: Amit Shah <amit.shah@redhat.com> Message-Id: <1469785705-16670-1-git-send-email-den@openvz.org> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-08-11migration/ram: fix typoCao jin1-2/+2
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Message-Id: <1469776231-23820-1-git-send-email-caoj.fnst@cn.fujitsu.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-08-08qjson: free strMarc-André Lureau1-0/+1
Release the qstring allocated in qjson_new(). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-07-22migration: set state to post-migrate on failureDr. David Alan Gilbert1-0/+4
If a migration fails/is cancelled during the postcopy stage we currently end up with the runstate as finish-migrate, where it should be post-migrate. There's a small window in precopy where I think the same thing can happen, but I've never seen it. It rarely matters; the only postcopy case is if you restart a migration, which again is a case that rarely matters in postcopy because it's only safe to restart the migration if you know the destination hasn't been running (which you might if you started the destination with -S and hadn't got around to 'c' ing it before the postcopy failed). Even then it's a small window but potentially you could hit if there's a problem loading the devices on the destination. This corresponds to: https://bugzilla.redhat.com/show_bug.cgi?id=1355683 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Message-Id: <1468601086-32117-1-git-send-email-dgilbert@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-07-13hmp: show all of snapshot info on every block dev in output of 'info snapshots'Lin Ma1-7/+90
Currently, the output of 'info snapshots' shows fully available snapshots. It's opaque, hides some snapshot information to users. It's not convenient if users want to know more about all of snapshot information on every block device via monitor. Follow Kevin's and Max's proposals, The patch makes the output more detailed: (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- checkpoint-1 165M 2016-05-22 16:58:07 00:02:06.813 List of partial (non-loadable) snapshots on 'drive_image1': ID TAG VM SIZE DATE VM CLOCK 1 snap1 0 2016-05-22 16:57:31 00:01:30.567 Signed-off-by: Lin Ma <lma@suse.com> Message-id: 1467869164-26688-3-git-send-email-lma@suse.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2016-07-13hmp: use snapshot name to determine whether a snapshot is 'fully available'Lin Ma1-1/+5
Currently qemu uses snapshot id to determine whether a snapshot is fully available, It causes incorrect output in some scenario. For instance: (qemu) info block drive_image1 (#block113): /opt/vms/SLES12-SP1-JeOS-x86_64-GM/disk0.qcow2 (qcow2) Cache mode: writeback drive_image2 (#block349): /opt/vms/SLES12-SP1-JeOS-x86_64-GM/disk1.qcow2 (qcow2) Cache mode: writeback (qemu) (qemu) info snapshots There is no snapshot available. (qemu) (qemu) snapshot_blkdev_internal drive_image1 snap1 (qemu) (qemu) info snapshots There is no suitable snapshot available (qemu) (qemu) savevm checkpoint-1 (qemu) (qemu) info snapshots ID TAG VM SIZE DATE VM CLOCK 1 snap1 0 2016-05-22 16:57:31 00:01:30.567 (qemu) $ qemu-img snapshot -l disk0.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 snap1 0 2016-05-22 16:57:31 00:01:30.567 2 checkpoint-1 165M 2016-05-22 16:58:07 00:02:06.813 $ qemu-img snapshot -l disk1.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 checkpoint-1 0 2016-05-22 16:58:07 00:02:06.813 The patch uses snapshot name instead of snapshot id to determine whether a snapshot is fully available and uses '--' instead of snapshot id in output because the snapshot id is not guaranteed to be the same on all images. For instance: (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- checkpoint-1 165M 2016-05-22 16:58:07 00:02:06.813 Signed-off-by: Lin Ma <lma@suse.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 1467869164-26688-2-git-send-email-lma@suse.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2016-07-13coroutine: move entry argument to qemu_coroutine_createPaolo Bonzini1-2/+2
In practice the entry argument is always known at creation time, and it is confusing that sometimes qemu_coroutine_enter is used with a non-NULL argument to re-enter a coroutine (this happens in block/sheepdog.c and tests/test-coroutine.c). So pass the opaque value at creation time, for consistency with e.g. aio_bh_new. Mostly done with the following semantic patch: @ entry1 @ expression entry, arg, co; @@ - co = qemu_coroutine_create(entry); + co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry2 @ expression entry, arg; identifier co; @@ - Coroutine *co = qemu_coroutine_create(entry); + Coroutine *co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry3 @ expression entry, arg; @@ - qemu_coroutine_enter(qemu_coroutine_create(entry), arg); + qemu_coroutine_enter(qemu_coroutine_create(entry, arg)); @ reentry @ expression co; @@ - qemu_coroutine_enter(co, NULL); + qemu_coroutine_enter(co); except for the aforementioned few places where the semantic patch stumbled (as expected) and for test_co_queue, which would otherwise produce an uninitialized variable warning. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-06-20trace: split out trace events for migration/ directoryDaniel P. Berrange1-0/+209
Move all trace-events for files in the migration/ directory to their own file. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1466066426-16657-6-git-send-email-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-17migration: code clean upLiang Li1-21/+15
Use 'QemuMutex comp_done_lock' and 'QemuCond comp_done_cond' instead of 'QemuMutex *comp_done_lock' and 'QemuCond comp_done_cond'. To keep consistent with 'QemuMutex decomp_done_lock' and 'QemuCond comp_done_cond'. Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-10-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: refine the decompression codeLiang Li1-25/+25
The current code for multi-thread decompression is not clear, especially in the aspect of using lock. Refine the code to make it clear. Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-9-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: refine the compression codeLiang Li1-44/+40
The current code for multi-thread compression is not clear, especially in the aspect of using lock. Refine the code to make it clear. Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-8-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: protect the quit flag by lockLiang Li1-16/+16
quit_comp_thread and quit_decomp_thread are accessed by several thread, it's better to protect them with locks. We use a per thread flag to replace the global one, and the new flag is protected by a lock. Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-7-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: refine ram_save_compressed_pageLiang Li1-14/+13
Use qemu_put_compression_data to do the compression directly instead of using do_compress_ram_page, avoid some data copy. very small improvement, at the same time, add code to check if the compression is successful. Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-6-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17qemu-file: Fix qemu_put_compression_data flawLiang Li2-7/+34
Current qemu_put_compression_data can only work with no writable QEMUFile, and can't work with the writable QEMUFile. But it does not provide any measure to prevent users from using it with a writable QEMUFile. We should fix this flaw to make it works with writable QEMUFile. Signed-off-by: Liang Li <liang.z.li@intel.com> Suggested-by: Juan Quintela <quintela@redhat.com> Message-Id: <1462433579-13691-5-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: remove useless codeLiang Li1-1/+0
page_buffer is set twice repeatedly, remove the previous set. Signed-off-by: Liang Li <liang.z.li@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1462433579-13691-4-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: Fix a potential issueLiang Li1-0/+19
At the end of live migration and before vm_start() on the destination side, we should make sure all the decompression tasks are finished, if this can not be guaranteed, the VM may get the incorrect memory data, or the updated memory may be overwritten by the decompression thread. Add the code to fix this potential issue. Suggested-by: David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-3-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: Fix multi-thread compression bugLiang Li1-11/+27
Recently, a bug related to multiple thread compression feature for live migration is reported. The destination side will be blocked during live migration if there are heavy workload in host and memory intensive workload in guest, this is most likely to happen when there is one decompression thread. Some parts of the decompression code are incorrect: 1. The main thread receives data from source side will enter a busy loop to wait for a free decompression thread. 2. A lock is needed to protect the decomp_param[idx]->start, because it is checked in the main thread and is updated in the decompression thread. Fix these two issues by following the code pattern for compression. Signed-off-by: Liang Li <liang.z.li@intel.com> Reported-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Tested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Liang Li <liang.z.li@intel.com> Message-Id: <1462433579-13691-2-git-send-email-liang.z.li@intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: fix inability to save VM after snapshotDenis V. Lunev1-1/+11
The following sequence of operations fails: virsh start vm virsh snapshot-create vm virshh save vm --file file with the following error error: Failed to save domain vm to file error: internal error: unable to execute QEMU command 'migrate': There's a migration process in progress The problem is that qemu_savevm_state() calls migrate_init() which sets migration state to MIGRATION_STATUS_SETUP and never cleaned it up. This patch do the job. Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> CC: Juan Quintela <quintela@redhat.com> CC: Amit Shah <amit.shah@redhat.com> Message-Id: <1466003203-26263-1-git-send-email-den@openvz.org> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-17migration: Trace improvementsDr. David Alan Gilbert1-6/+7
A couple of improvements to tracing that have come out of helping people with migration problems: * vmstate_n_elems trace the count/name - for when you have problems getting array counts right * vmstate_subsection_load_bad - add the idstr, for when you receive a subsection you weren't expecting. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1465896986-16132-1-git-send-email-dgilbert@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
generated by cgit v1.1 at 2025-01-01 15:46:25 +0000