diff options
| author | Daniel P. Berrange <berrange@redhat.com> | 2017-04-21 12:12:20 +0100 |
|---|---|---|
| committer | Juan Quintela <quintela@redhat.com> | 2017-05-04 10:00:38 +0200 |
| commit | 062d81f0e968fe1597474735f3ea038065027372 (patch) | |
| tree | 38a71ca56da6015ad59190bc48fb8e279c0aebe7 /migration/exec.c | |
| parent | 6b6712efccd383b48a909bee0b29e079a57601ec (diff) | |
migration: setup bi-directional I/O channel for exec: protocol
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>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Diffstat (limited to 'migration/exec.c')
| -rw-r--r-- | migration/exec.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/migration/exec.c b/migration/exec.c index 9157721dfe..aba9089466 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; |