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(a)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(a)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