Message ID | 20170421111220.32673-1-berrange@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
"Daniel P. Berrange" <berrange@redhat.com> wrote: > Historically the migration data channel has only needed to be > unidirectional. Thus the 'exec:' protocol was requesting an > I/O channel with O_RDONLY on incoming side, and O_WRONLY on > the outgoing side. > > This is fine for classic migration, but if you then try to run > TLS over it, this fails because the TLS handshake requires a > bi-directional channel. > > Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Actually, lots of people request that we have bi-directional communication always that it is possible.
diff --git a/migration/exec.c b/migration/exec.c index 9157721..aba9089 100644 --- a/migration/exec.c +++ b/migration/exec.c @@ -32,7 +32,7 @@ void exec_start_outgoing_migration(MigrationState *s, const char *command, Error trace_migration_exec_outgoing(command); ioc = QIO_CHANNEL(qio_channel_command_new_spawn(argv, - O_WRONLY, + O_RDWR, errp)); if (!ioc) { return; @@ -59,7 +59,7 @@ void exec_start_incoming_migration(const char *command, Error **errp) trace_migration_exec_incoming(command); ioc = QIO_CHANNEL(qio_channel_command_new_spawn(argv, - O_RDONLY, + O_RDWR, errp)); if (!ioc) { return;
Historically the migration data channel has only needed to be unidirectional. Thus the 'exec:' protocol was requesting an I/O channel with O_RDONLY on incoming side, and O_WRONLY on the outgoing side. This is fine for classic migration, but if you then try to run TLS over it, this fails because the TLS handshake requires a bi-directional channel. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- migration/exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)