> On 21 Mar 2019, at 19:12, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> On Thu, Mar 21, 2019 at 06:31:35PM +0200, Liran Alon wrote:
>>
>>
>>> On 21 Mar 2019, at 17:50, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>>>
>>> On Thu, Mar 21, 2019 at 08:45:17AM -0700, Stephen Hemminger wrote:
>>>> On Thu, 21 Mar 2019 15:04:37 +0200
>>>> Liran Alon <liran.alon@xxxxxxxxxx> wrote:
>>>>
>>>>>>
>>>>>> OK. Now what happens if master is moved to another namespace? Do we need
>>>>>> to move the slaves too?
>>>>>
>>>>> No. Why would we move the slaves? The whole point is to make most customer ignore the net-failover slaves and remain them “hidden” in their dedicated netns.
>>>>> We won’t prevent customer from explicitly moving the net-failover slaves out of this netns, but we will not move them out of there automatically.
>>>>
>>>>
>>>> The 2-device netvsc already handles case where master changes namespace.
>>>
>>> Is it by moving slave with it?
>>
>> See c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc device”).
>> It seems that when NetVSC master netdev changes netns, the VF is moved to the same netns by the NetVSC driver.
>> Kinda the opposite than what we are suggesting here to make sure that the net-failover master netdev is on a separate
>> netns than it’s slaves...
>>
>> -Liran
>>
>>>
>>> --
>>> MST
>
> Not exactly opposite I'd say.
>
> If failover is in host ns, slaves in /primary and /standby, then moving
> failover to /container should move slaves to /container/primary and
> /container/standby.
Yes I agree.
I meant that they tried to keep the VF on the same netns as the NetVSC.
But of course what you just described is exactly the functionality I would have wanted in our net-failover mechanism.
-Liran
>
>
> --
> MST
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
