- 30 10月, 2016 7 次提交
-
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: NGonglei <arei.gonglei@huawei.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NGonglei <arei.gonglei@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: NGonglei <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: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
This new communication path will be used for returning messages from Secondary side to Primary side. Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: NGonglei <arei.gonglei@huawei.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-
由 zhanghailiang 提交于
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: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: NGonglei <arei.gonglei@huawei.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NAmit Shah <amit@amitshah.net>
-