2009/11/26 Daniel Hokka Zakrisson <email@example.com>:
>>> /proc/virtual/<xid>/info contains the initpid as
>>> seen from the host (for init virtualization)
> Note that most guests actually won't have an init though.
Well, maybe not sysvinit, but they will have a process that can be
attached to, no? Persistent contexts (without any process inside)
might be a problem though.
>> 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...
If the point of the pid is to be simply passed to the kernel, I guess
we'd just need the correct value and the kernel may simply ignore the
>> 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.
Even if I'd create a guest with a netns and a xid but without a nid
(which is what recent util-vserver does when asked for a netns,
AFAIK)? I'd like network contexts completely decoupled from "xid"
Straying a further bit off topic, did anybody try replacing VServer
components with mainline features? I.e. using namespaces and cgroups
instead of VServer contexts?
Received on Thu Nov 26 19:41:55 2009