2009/11/26 Daniel Hokka Zakrisson <daniel@hozac.com>: >>> /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. 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 host/guest distinction. >> 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" contexts. 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? Best regards, Grzegorz Nosek