On Thu, Nov 26, 2009 at 05:12:10PM +0100, Grzegorz Nosek wrote: > 2009/11/26 Herbert Poetzl <herbert@13thfloor.at>: > >> I see the recent util-vserver snapshots provide a tool called vspace > >> and some options in /etc/vservers, although they don't configure the > >> network in any meaningful way (e.g. by creating a macvlan device or a > >> pair of veths or something). > > patches are welcome I guess .... > Yeah, I suppose so. Awaiting a shipment of round tuits. > >> Please consider for the next release. > > yep, will include that .. thanks again! > Thanks a lot. > >> On a related note, is anybody trying to make Linux-VServer coexist > >> nicely with network namespaces? I'd rather not reinvent the wheel. > > not much work has been done on that part, so feel > > free to test and report any issues as well as submit > > patches for inclusion and of course, write a wiki > > page how to use them properly ... > Well, there's not much to report on right now as util-vserver simply > creates a guest without network interfaces (OK, I did get lo and > sit0). I hope I'll have some code to share but right now I have > nothing to share either. > > /proc/virtual/<xid>/info contains the initpid as > > seen from the host (for init virtualization) > Thanks. > >> It's required for setting up (net) namespaces. > > interesting ... how so? > Well, the only interface I know that allows moving network interfaces > between namespaces (which is an essential step to provide a guest with > connectivity) is using iproute: > ip link set dev <interface> netns <pid-of-somebody-in-the-right-namespace> hmm, okay, interesting approach, but I guess we can add 'other' interfaces when there is a need for > As iproute isn't exactly well known for heavy layers of abstraction, > I assume this is the interface exposed by the kernel too. Or does > Linux-VServer provide something else? not yet, but as I said, if there is a need for it, I'm sure we can provide some interfaces ... > BTW, Do you foresee any problems with a setup comprising a network > namespace per guest and multiple network contexts inside? As in all > users of a guest share their (virtualised) view of network interfaces, > but still they are limited to different subsets of IP addresses. I'd > really love it. I don't see why network contexts should not work inside a network namespace ... but I haven't tried it either ... best, Herbert > Best regards, > Grzegorz Nosek