From: Pavel Emelianov <xemul@openvz.org>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Patrick McHardy <kaber@trash.net>,
Linux Containers <containers@lists.osdl.org>,
Linux Netdev List <netdev@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kirill Korotaev <dev@openvz.org>
Subject: Re: [PATCH] Virtual ethernet tunnel
Date: Thu, 07 Jun 2007 13:51:52 +0400 [thread overview]
Message-ID: <4667D538.7040904@openvz.org> (raw)
In-Reply-To: <4667D00E.2020605@fr.ibm.com>
>> I did this at the very first version, but Alexey showed me that this
>> would be wrong. Look. When we create the second device it must be in
>> the other namespace as it is useless to have them in one namespace.
>> But if we have the device in the other namespace the RTNL_NEWLINK
>> message from kernel would come into this namespace thus confusing ip
>> utility in the init namespace. Creating the device in the init ns and
>> moving it into the new one is rather a complex task.
>>
> Pavel,
>
> moving the netdevice to another namespace is not a complex task. Eric
> Biederman did it in its patchset ( cf. http://lxc.sf.net/network )
By saying complex I didn't mean that this is difficult to implement,
but that it consists (must consist) of many stages. I.e. composite.
Making the device right in the namespace is liter.
> When the pair device is created, both extremeties are into the init
> namespace and you can choose to which namespace to move one extremity.
I do not mind that.
> When the network namespace dies, the netdev is moved back to the init
> namespace.
> That facilitate network device management.
>
> Concerning netlink events, this is automatically generated when the
> network device is moved through namespaces.
>
> IMHO, we should have the network device movement between namespaces in
> order to be able to move a physical network device too (eg. you have 4
> NIC and you want to create 3 containers and assign 3 NIC to each of them)
Agree. Moving the devices is a must-have functionality.
I do not mind making the pair in the init namespace and move the second
one into the desired namespace. But if we *always* will have two ends in
different namespaces what to complicate things for?
Thanks,
Pavel
next prev parent reply other threads:[~2007-06-07 9:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-06 15:11 [PATCH] Virtual ethernet tunnel Pavel Emelianov
2007-06-06 15:17 ` [PATCH] Module for ip utility to support veth device Pavel Emelianov
2007-06-06 15:18 ` Patrick McHardy
2007-06-06 15:28 ` [PATCH] Virtual ethernet tunnel Patrick McHardy
2007-06-07 8:09 ` Pavel Emelianov
2007-06-07 9:29 ` Daniel Lezcano
2007-06-07 9:51 ` Pavel Emelianov [this message]
2007-06-07 14:05 ` Daniel Lezcano
2007-06-07 14:23 ` Kirill Korotaev
2007-06-07 14:42 ` Daniel Lezcano
2007-06-07 15:33 ` Pavel Emelianov
2007-06-07 15:25 ` Pavel Emelianov
2007-06-07 15:44 ` Daniel Lezcano
2007-06-11 11:39 ` Patrick McHardy
2007-06-13 9:24 ` Pavel Emelianov
2007-06-13 11:12 ` Patrick McHardy
2007-06-13 16:02 ` Pavel Emelianov
2007-06-13 15:37 ` Patrick McHardy
2007-06-06 15:39 ` Patrick McHardy
2007-06-06 16:17 ` Stephen Hemminger
2007-06-06 19:47 ` David Miller
2007-06-06 20:38 ` [Devel] " Daniel Lezcano
2007-06-06 20:49 ` David Miller
2007-06-07 8:14 ` Kirill Korotaev
2007-06-07 9:07 ` David Miller
2007-06-07 9:30 ` Benjamin Thery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4667D538.7040904@openvz.org \
--to=xemul@openvz.org \
--cc=containers@lists.osdl.org \
--cc=dev@openvz.org \
--cc=dlezcano@fr.ibm.com \
--cc=ebiederm@xmission.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.