| commit | 062d81f0e968fe1597474735f3ea038065027372 | |
| author | Daniel P. Berrange <berrange@redhat.com> | |
| Fri, 21 Apr 2017 11:12:20 +0000 (21 12:12 +0100) | ||
| committer | Juan Quintela <quintela@redhat.com> | |
| Thu, 4 May 2017 08:00:38 +0000 (4 10:00 +0200) | ||
| tree | 38a71ca56da6015ad59190bc48fb8e279c0aebe7 | treesnapshot (tar.gz zip) |
| parent | 6b6712efccd383b48a909bee0b29e079a57601ec | commitdiff |
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>
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>
| migration/exec.c | diffblobblamehistory |