Re: which daemon/service for live migration - ?
On Mon, Apr 17, 2023 at 16:38:17 +0200, lejeczek wrote:
On 17/04/2023 15:34, Peter Krempa wrote:
> On Mon, Apr 17, 2023 at 14:39:18 +0200, lejeczek wrote:
> >
> > On 17/04/2023 14:31, Peter Krempa wrote:
> > > On Mon, Apr 17, 2023 at 14:24:32 +0200, lejeczek wrote:
[...]
> If you think more explanation is needed then please submit a
issue and
> describe your request and suggestion how you'd like that to be worded.
>
I do. I did - I said that it appeared to be more specific.
I said:
"
migration with 'qemu+tls' fails if receiving node does not have
'virtproxyd-tls.socket' up&running,
even though 'virtproxyd.socket' & 'virtqemud.service' are running on
that
node.
"
I'm sorry but 'migration' fairly and squarely fits into 'remote
access'
category IMO. The only reasonable way I can see this changed is to do
e.g.
Remote off-host (TLS socket) access ...
Enumerating everything that needs it doesn't make much sense the
document would become even more off-putting for others to read. Over
recent times I've made a similar mistake with trying to improve the
knowledge base page about debug logging to put every possible scenario
based on what people were doing wrong, and the document is now so
massive that people simple don't read it.
I said - if that is the business logic, also for 'tcp' - then
those would
certainly be worth an explanation in man pages. Saves many some time.
TCP is insecure and deprecated and should not be used for any real
use case.