Hi Jason,
On 2017/4/14 14:38, Jason Wang wrote:
On 2017年04月14日 14:22, Hailiang Zhang wrote:
Hi Jason,
On 2017/4/14 13:57, Jason Wang wrote:
On 2017年02月22日 17:31, Zhang Chen wrote:
On 02/22/2017 11:42 AM, zhanghailiang wrote:
While do checkpoint, we need to flush all the unhandled packets,
By using the filter notifier mechanism, we can easily to notify
every compare object to do this process, which runs inside
of compare threads as a coroutine.
Hi~ Jason and Hailiang.
I will send a patch set later about colo-compare notify mechanism for
Xen like this patch.
I want to add a new chardev socket way in colo-comapre connect to Xen
colo, for notify
checkpoint or failover, Because We have no choice to use this way
communicate with Xen codes.
That's means we will have two notify mechanism.
What do you think about this?
Thanks
Zhang Chen
I was thinking the possibility of using similar way to for colo
compare.
E.g can we use socket? This can saves duplicated codes more or less.
Since there are too many sockets used by filter and COLO, (Two unix
sockets and two
tcp sockets for each vNIC), I don't want to introduce more ;) , but
i'm not sure if it is
possible to make it more flexible and optional, abstract these
duplicated codes,
pass the opened fd (No matter eventfd or socket fd ) as parameter, for
example.
Is this way acceptable ?
Thanks,
Hailiang
Yes, that's kind of what I want. We don't want to use two message
format. Passing a opened fd need management support, we still need a
fallback if there's no management on top. For qemu/kvm, we can do all
stuffs transparent to the cli by e.g socketpair() or others, but the key
is to have a unified message format.
After a deeper investigation, i think we can re-use most codes, since
there is no
existing way to notify xen (no ?), we still needs notify chardev
socket (Be used to notify xen, it is optional.)
(http://patchwork.ozlabs.org/patch/733431/ "COLO-compare: Add Xen
notify chardev socket handler frame")
Besides, there is an existing qmp comand 'xen-colo-do-checkpoint', we
can re-use it to notify
colo-compare objects and other filter objects to do checkpoint, for
the opposite direction, we use
the notify chardev socket (Only for xen).
So the codes will be like:
diff --git a/migration/colo.c b/migration/colo.c
index 91da936..813c281 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -224,7 +224,19 @@ ReplicationStatus
*qmp_query_xen_replication_status(Error **errp)
void qmp_xen_colo_do_checkpoint(Error **errp)
{
+ Error *local_err = NULL;
+
replication_do_checkpoint_all(errp);
+ /* Notify colo-compare and other filters to do checkpoint */
+ colo_notify_compares_event(NULL, COLO_CHECKPOINT, &local_err);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ return;
+ }
+ colo_notify_filters_event(COLO_CHECKPOINT, &local_err);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ }
}
static void colo_send_message(QEMUFile *f, COLOMessage msg,
diff --git a/net/colo-compare.c b/net/colo-compare.c
index 24e13f0..de975c5 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -391,6 +391,9 @@ static void colo_compare_inconsistent_notify(void)
{
notifier_list_notify(&colo_compare_notifiers,
migrate_get_current());
+ if (s->notify_dev) {
+ /* Do something, notify remote side through notify dev */
+ }
}
void colo_compare_register_notifier(Notifier *notify)
How about this scenario ？