Patchwork [RFC,2/4] Curling: cmdline interface

login
register
mail settings
Submitter Jules Wang
Date Sept. 10, 2013, 3:43 a.m.
Message ID <1378784607-7398-3-git-send-email-junqing.wang@cs2c.com.cn>
Download mbox | patch
Permalink /patch/273883/
State New
Headers show

Comments

Jules Wang - Sept. 10, 2013, 3:43 a.m.
Parse the word 'curling' when incoming/outgoing migration is
starting. So we know whether to enable fault tolerant or not.

Signed-off-by: Jules Wang <junqing.wang@cs2c.com.cn>
---
 include/migration/migration.h |  2 ++
 migration.c                   | 16 ++++++++++++++++
 2 files changed, 18 insertions(+)
Paolo Bonzini - Sept. 10, 2013, 2:38 p.m.
Il 10/09/2013 18:37, Juan Quintela ha scritto:
>> I think for the outgoing side it should just be "migrate -f tcp:foo:9999".
>>
>> On the incoming side, perhaps you could have a different ID instead of
>> QEMU_VM_FILE_MAGIC, that triggers fault-tolerance mode automatically?
>> Then again it would be simply "-incoming tcp:foo:9999".
> 
> Then how can you distingish between faultolerance and simple migration?
> You need to diferentiate on both sides.
> 
> - outgoing side: you need to continue running after sending the whole
>   state
> - incoming side: after receivinga lot,  you apply it,  and have to wait
>   for the next one.
> 
> It is a different thing to do,  we need to tell qemu somehow.

You look at the first 4 bytes in the stream and distinguish the two cases.

Paolo
Juan Quintela - Sept. 10, 2013, 3:21 p.m.
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 10/09/2013 18:37, Juan Quintela ha scritto:
>>> I think for the outgoing side it should just be "migrate -f tcp:foo:9999".
>>>
>>> On the incoming side, perhaps you could have a different ID instead of
>>> QEMU_VM_FILE_MAGIC, that triggers fault-tolerance mode automatically?
>>> Then again it would be simply "-incoming tcp:foo:9999".
>> 
>> Then how can you distingish between faultolerance and simple migration?
>> You need to diferentiate on both sides.
>> 
>> - outgoing side: you need to continue running after sending the whole
>>   state
>> - incoming side: after receivinga lot,  you apply it,  and have to wait
>>   for the next one.
>> 
>> It is a different thing to do,  we need to tell qemu somehow.
>
> You look at the first 4 bytes in the stream and distinguish the two cases.

We need to change how things are handled.  Are we sure we don't want
curling over exec/unix/fd?
Juan Quintela - Sept. 10, 2013, 3:22 p.m.
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 10/09/2013 18:37, Juan Quintela ha scritto:
>>> I think for the outgoing side it should just be "migrate -f tcp:foo:9999".
>>>
>>> On the incoming side, perhaps you could have a different ID instead of
>>> QEMU_VM_FILE_MAGIC, that triggers fault-tolerance mode automatically?
>>> Then again it would be simply "-incoming tcp:foo:9999".
>> 
>> Then how can you distingish between faultolerance and simple migration?
>> You need to diferentiate on both sides.
>> 
>> - outgoing side: you need to continue running after sending the whole
>>   state
>> - incoming side: after receivinga lot,  you apply it,  and have to wait
>>   for the next one.
>> 
>> It is a different thing to do,  we need to tell qemu somehow.
>
> You look at the first 4 bytes in the stream and distinguish the two cases.

We need to change how things are handled, but nothing too complicated.
Are we sure we don't want curling over exec/unix/fd?

Later, Juan.
Juan Quintela - Sept. 10, 2013, 4:37 p.m.
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 10/09/2013 15:57, Juan Quintela ha scritto:
>>> >  
>>> > +    if (strstart(uri, "curling:", &p)) {
>>> > +        ft_mode = true;
>>> > +        uri = p;
>>> > +    }
>>> > +
>> Syntax is at least weird:
>> 
>> curling:tcp:foo:9999
>> 
>> curling+tcp:foo:9999 
>> 
>> could be better?  Suggestions folks?
>> 
>> notice that we still need more things: tcp+tls should happen at some
>> time soon.  This is not related with this patch.
>> 
>
> I think for the outgoing side it should just be "migrate -f tcp:foo:9999".
>
> On the incoming side, perhaps you could have a different ID instead of
> QEMU_VM_FILE_MAGIC, that triggers fault-tolerance mode automatically?
> Then again it would be simply "-incoming tcp:foo:9999".

Then how can you distingish between faultolerance and simple migration?
You need to diferentiate on both sides.

- outgoing side: you need to continue running after sending the whole
  state
- incoming side: after receivinga lot,  you apply it,  and have to wait
  for the next one.

It is a different thing to do,  we need to tell qemu somehow.

> Paolo
Jules Wang - Sept. 11, 2013, 2:51 a.m.
> Shouldn't this be in migration_state?  Just wondering.  And yes,  I
> don't see either a trivial place how to get it.  get_current_migration()?

That's a better idea, I will put 'ft_enabled'  in MigrationState Struct.

> I think for the outgoing side it should just be "migrate -f tcp:foo:9999".
> On the incoming side, perhaps you could have a different ID instead of
> QEMU_VM_FILE_MAGIC, that triggers fault-tolerance mode automatically?

I am OK with this solution,  '-f'  indicates fault-tolerance, right?


Have youdecided yet?

Patch

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 140e6b4..4cbb62f 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -162,4 +162,6 @@  size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
                              ram_addr_t offset, size_t size,
                              int *bytes_sent);
 
+bool ft_enabled(void);
+
 #endif
diff --git a/migration.c b/migration.c
index 200d404..59c8f32 100644
--- a/migration.c
+++ b/migration.c
@@ -58,6 +58,12 @@  enum {
 static NotifierList migration_state_notifiers =
     NOTIFIER_LIST_INITIALIZER(migration_state_notifiers);
 
+static bool ft_mode;
+bool ft_enabled(void)
+{
+    return ft_mode;
+}
+
 /* When we add fault tolerance, we could have several
    migrations at once.  For now we don't need to add
    dynamic creation of migration */
@@ -78,6 +84,11 @@  void qemu_start_incoming_migration(const char *uri, Error **errp)
 {
     const char *p;
 
+    if (strstart(uri, "curling:", &p)) {
+        ft_mode = true;
+        uri = p;
+    }
+
     if (strstart(uri, "tcp:", &p))
         tcp_start_incoming_migration(p, errp);
 #ifdef CONFIG_RDMA
@@ -420,6 +431,11 @@  void qmp_migrate(const char *uri, bool has_blk, bool blk,
 
     s = migrate_init(&params);
 
+    if (strstart(uri, "curling:", &p)) {
+        ft_mode = true;
+        uri = p;
+    }
+
     if (strstart(uri, "tcp:", &p)) {
         tcp_start_outgoing_migration(s, p, &local_err);
 #ifdef CONFIG_RDMA