----- Original Message -----
> [...]
> (Note: I've never used containers on Linux, so I don't know what their
> limitations/annoyances are. Therefore, I may be missing something totally
> obvious that answers my questions - sorry.)
>
> Interesting. As a Illumos (OpenSolaris-fork) fan & developer, I'm curious
> if you've given any thought to what this would mean for Solaris/Illumos
> zones.
Yep, a little, the code has been arranged to allow multiple container engines
to be supported (there are already many on Linux), hopefully that will prove
extensible to Solaris too.
> There, the global zone has access to all the state of the non-global zones.
> E.g., the list of mounts includes *all* the mounts across all the zones; the
> list of processes includes *all* processes on the system. (If you are in a
> non-global zone, you only see processes/mounts/etc. related to the zone you
> are in.) I bring this up because a large-ish portion of the above link
> seems to talk about how to deal with state extraction across the container
> boundary.
>
> FWIW, zones get a integer ID when they boot (rebooting a zone will change
> its ID). There's a way to map it to a user-supplied zone name which is
> persistent across zone reboots.
That's exactly the kind of stuff we need to know about in the PCP collector
code. I'm planning a little writeup of using the container instrumentation
so far, which might help us here a little with exchanging ideas. If you're
interested in some Solaris zone PCP hacking though, the place to start will
be digging into what per-zone instrumentation exists, how to access it, how
to enumerate the set of zones, etc - and then we can dovetail that into the
work that's being done for Linux.
cheers.
--
Nathan
|