[PATCH v1 25/25] docs/kbase: introduce migrationinternals.rst

[Daniel Henrique Barboza]

On 7/13/20 11:32 AM, Michal Privoznik wrote:
> On 7/13/20 3:42 PM, Daniel Henrique Barboza wrote:
>>
>>
>> On 7/13/20 10:20 AM, Michal Privoznik wrote:
>>> On 7/13/20 11:49 AM, Daniel Henrique Barboza wrote:
>>>> This document describes briefly how Libvirt migration internals
>>>> works, complementing the info available in migration.html.in.
>>>>
>>>> Signed-off-by: Daniel Henrique Barboza <danielhb413 at gmail.com>
>>>> ---
>>>>   docs/kbase/migrationinternals.rst | 174 ++++++++++++++++++++++++++++++
>>>>   1 file changed, 174 insertions(+)
>>>>   create mode 100644 docs/kbase/migrationinternals.rst
>>>>
>>>> diff --git a/docs/kbase/migrationinternals.rst b/docs/kbase/migrationinternals.rst
>>>> new file mode 100644
>>>> index 0000000000..869ee99bd7
>>>> --- /dev/null
>>>> +++ b/docs/kbase/migrationinternals.rst
>>>> @@ -0,0 +1,174 @@
>>>> +===========================
>>>> +Libvirt migration internals
>>>> +===========================
>>>> +
>>>> +.. contents::
>>>> +
>>>> +Migration is a multi-step operation with at least two distinct actors,
>>>> +the source and the destination libvirtd daemons, and a lot of failure
>>>> +points. This document describes the basic migration workflow in the
>>>> +code level, as a way to complement `the base migration docs <migration.html>`_
>>>> +and help developers to get up to speed quicker with the code.
>>>> +
>>>> +In this document, unless stated otherwise, these conventions are followed:
>>>> +
>>>> +* 'user' refers to any entity that initiates a migration, regardless of being
>>>> +  an human using 'virsh' or a program consuming the Libvirt API;
>>>> +
>>>> +* 'source' refers to the source host of the migration, where the guest currently
>>>> +  exists;
>>>> +
>>>> +* 'destination' refers to the destination host of the migration. As of
>>>> +  Libvirt 6.5.0 local migration isn't supported, thus source and destination
>>>> +  refers to different hosts;
>>>
>>> Is this right? What commit is reponsible for this change?
>>
>>
>> I guess my wording here is unclear. What I wanted to say is that, at least up to the
>> current release we're at now (6.5.0), localhost migration (i.e. source and destination
>> is the same host) isn't supported. I wanted to mention it this way because  there's always
>> the chance that Libvirt comes around and implements it.
>>
>>
>>
>> If you want a commit id, the error message warning about localhost migration appeared
>> first here:
>>
>>
>> commit 8654175c5b0c3db9e5f70907f102f0f900355d28
>> Author: Daniel P. Berrange <berrange at redhat.com>
>> Date:   Mon Jan 24 18:06:16 2011 +0000
> 
> Yeah, I was more interested whether we merged recently a patch that explicitly forbids same host migration. Speaking of which, to some extent we support same host migration (see v6.2.0-rc1~282) if both libvirts live in separate containers (and effectively think they run on different hosts).

Yeah, I believe k8s/kubevirt makes what I mentioned up there deprecated, since
two nodes of the cluster are treated as complete different domains regardless
of them being in the same host.

This alone would make too much of a paragraph just to explain what I meant with
'destination'. Perhaps we should just stick it to the basics:


$ git diff
diff --git a/docs/kbase/migrationinternals.rst b/docs/kbase/migrationinternals.rst
index 869ee99bd7..29bda0443b 100644
--- a/docs/kbase/migrationinternals.rst
+++ b/docs/kbase/migrationinternals.rst
@@ -18,9 +18,7 @@ In this document, unless stated otherwise, these conventions are followed:
  * 'source' refers to the source host of the migration, where the guest currently
    exists;
  
-* 'destination' refers to the destination host of the migration. As of
-  Libvirt 6.5.0 local migration isn't supported, thus source and destination
-  refers to different hosts;
+* 'destination' refers to the destination host of the migration;
  
  * 'libvirt client' refers to the Libvirt client process that controls the
    migration flow, e.g. virsh. Note that this client process can reside in



Thanks,


DHB


> 
> Can you post a diff that I can squash in before merging?
> 
> Michal
>