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.
Yep, no work has gone into it whatsoever. Patches most welcome.
>> /proc/virtual/<xid>/info contains the initpid as
>> seen from the host (for init virtualization)
>
> Thanks.
Note that most guests actually won't have an init though.
>>> 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>
>
> 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?
I think we'll have to, since the processes aren't visible from the host,
and you can't very well do that from the guest...
> 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.
That'll be highly problematic. You cannot manage contexts from within
a guest, so you'll need to do the setup on the host as well as putting
the processes in the right context. You wouldn't be able to enter or
restart services or anything inside the guest.
Daniel
Received on Thu Nov 26 17:33:02 2009