| Message ID | 1378784607-7398-3-git-send-email-junqing.wang@cs2c.com.cn |
|---|---|
| State | New |
| Headers | show |
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
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?
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.
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
> 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?
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(¶ms); + 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
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(+)