Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

From: "Black, David" <[email-masked]>
Date: Tue, 12 Dec 2017 15:31:02 +0000

I support publication of this draft as an author.

Here are a couple of follow-ups to Dale's VM-related comments:

>    2.2 VM Live Migration Event
>
> If we've initiated a migration from hypervisor 1 to hypervisor 2, before it is finished,
> can we initiate a migration from hypervisor 2 to hypervisor 3?  That is, does the CP
> have to support chained migrations-in-progress?
> [yz] I guess the tricky point is how the VM migration is supposed to react in this case.
> Will it be something like "abort and revert 1st migration and jump to the migration to
> hypervisor 3" or "finish the first migration gracefully and perform the second one
> immediately"?
> I do not think split-NVE control plane is necessarily to tell the difference or provide
> different functionalities for them. VM migration mechanism should take care of it.
> [/yz]

I agree, and would also answer "no" to Dale's original question.  Trying to chain or pipeline two live VM migrations complicates what has to happen in the brief period when VM execution is suspended to sync up the final memory changes and transfer execution to the destination hypervisor.  Aborting or completing the first migration before trying another is the only sane approach.

> From the split-NVE point of view, is there any difference between

> Paused and Suspended?

> [yz] No difference. Sub-section 2.4 just tries to explain VM keeps in association state in case of VM Pause or Suspension.

Actually, there is a secondary difference, as described in this text in Section 3.3, but take note of the use of "may" in the first sentence:

   A VM suspension event (discussed in section 2<https://tools.ietf.org/html/draft-ietf-nvo3-hpvr2nve-cp-req-10#section-2>) may cause the relevant

   TSI instance(s) on the NVE to transit from Activated to Associated

   state. A VM pause event normally does not affect the state of the

   relevant TSI instance(s) on the NVE as the VM is expected to run

   again soon. The VM shutdown event will normally cause the relevant

   TSI instance(s) on NVE transition to Init state from Activated state.

   All resources should be released.

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Liyizhou <[email-masked]>
Date: Wed, 13 Dec 2017 02:55:55 +0000

Hi David,

You are right about the potential implications of paused and suspended. I missed the text in section 3.3.

So we keep section 2.4 as it was with a minor change on the last sentence to accurately reflect the text in section 3.3 , i.e.

In the Split-NVE architecture, the external NVE should keep any paused or suspended VM in association as the VM can return to Running state at any time.
=>
In the Split-NVE architecture, the external NVE should not disassociate the paused or suspended VM as the VM can return to Running state at any time.

Thanks,
Yizhou

From: Black, David [mailto:[email-masked]]
Sent: Tuesday, December 12, 2017 11:31 PM
To: NVO3 <[email-masked]>
Cc: [email-masked]; Black, David <[email-masked]>
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

Thanks, --David