Sorry for my confusion. I tested TLS migration by using RDMA, as RDMA
traffic bypasses the CPU, the TLS setting is not validated. With TCP,
the connection can't be established if "endpoint" setting is wrong.
On Tue, Jun 11, 2024 at 5:57 PM Yu Zhang wrote:
>
> Hello Daniel and all,
>
> When I was
Hello Daniel and all,
When I was using TLS encryption for VM live-migration, I noticed one
thing: the migration works regardless of the "endpoint" setting (that
is: either "endpoint=server", or "endpoint=client") on the target
server.
The line I added is:
"-object tls-creds-x509,id=tls0,dir=/path/
Hello Daniel,
sorry for my slow reply! I tested the approach you suggested by the
following way:
On the target server, start a VM in -incoming mode:
qemu-7.1 \
-uuid ${VM_UUID} \
...
-object tls-creds-x509,id=tls0,dir=${HOME}/qemutls,endpoint=server \
...
-incoming defer \
-qmp unix:${SOCK},se
On Mon, Aug 07, 2023 at 12:07:31AM +0200, Yu Zhang wrote:
> Hi all,
>
> According to qemu docs [1], TLS parameters are specified as an object in
> the QEMU command line:
>
>-object tls-creds-x509,id=id,endpoint=endpoint,dir=/path/to/cred/dir ...
>
> of which "endpoint" is a type of "QCryptoT
Hi all,
According to qemu docs [1], TLS parameters are specified as an object in
the QEMU command line:
-object tls-creds-x509,id=id,endpoint=endpoint,dir=/path/to/cred/dir ...
of which "endpoint" is a type of "QCryptoTLSCredsEndpoint" and can be
either a "server" or a "client".
I'd like to