[lxc-devel] Just for giggles...

[Michael H. Warfield]

On Mon, 2010-02-01 at 08:12 +0100, Suno Ano wrote: 
> Mike> Hey all, Just for giggles, could we save the host PID of the
>  Mike> container init process in a file in /var/lib/lxc/${VM} somewhere?
> 
> +1 from me, sounds like a very useful thing to do. Might it be so that
> container A would want to know about that sort of thing from container B
> or vice versa?
> 
> That could all go into the same file (at least that would be a start),
> thus also allowing container A to check whether or not it is alone on
> the host system or how many others there might be ... maybe even do
> runtime adjustments on all containers with regards to bandwidth
> throttling/negotiation, disk I/O negotiation, dynamic CPU shares
> arrangements, etc.

> Sounds like a crazy idea, I know that, but does anybody else have any
> thoughts of giving containers "awareness" of its siblings and maybe
> their needs and current states as well? Does it make sense at all?

I actually would not really be in favor of that, although I might be
convinced otherwise.

In adhering to the whole virtualization philosophy, one machine really
should not depend on or care what its environment is, host machine on
hard iron, singly virtualized, or one amongst many.  For one thing, that
immediately complicates migration issues where one or more machines may
be migrated between several hosts.

In fact, I just did that in my "grand migration" from OpenVZ to LXC just
recently.

* Started with 3 hosts, A, B, and C, all Fedora 11.  A and C were OpenVZ
hosts with a net sum of over 3 dozen VZ containers.

* Migrated all the OpenVZ containers to A and brought B up with the
latest kernel and LXC.

* Shut down a couple of test containers and moved them to B and got them
working.

* Moved all but a few high storage containers to B and had them all
working.

* Updated C to latest distro, Fedora 12, and kernel.

* Migrated a few test containers to it and discovered the notorious
"unable to pivot root" problem and a workaround for that.

* Now migrated all 3 dozen remaining containers to C.

* Updated A to latest kernel and LXC.

Now, A and B are F11 with LXC and C is F12 with LXC and non are OpenVZ
capable any longer.  All the containers were on C at that point.

* Needed to try and help debug the "unable to pivot root" problem so I
remigrated most of the containers to B with a few going to A depending
on storage needs, and a couple of test containers remaining on C.  Then
discovered I no longer could reproduce the "unable to pivot root
problem" even with the earlier hack I used.  Sigh...

At this point the containers are, once again, distributed across 3 host
systems.  If the containers were aware of each other, should they then
also be aware of where they are and where the others are?  This could
get to be a very sticky problem and you never know how deep that rat
hole goes.  Container management and coordination should be done via the
host and via normal communications channels such as sockets and
networking and rpc's, and maybe service discovery.  I don't think we
should be attempting to reinvent those wheels.

> Coming from an OpenVZ/Linux-VServer environment, all there was were
> "static" settings i.e. once beancounter limits were set, they are set.
> Maybe having the thought of "A needs relatively two/three/22.7/whatever
> times the XY as does B" would be an entirely new concept altogether. XY
> would be e.g. disk space, bandwidth, CPU, etc.
> 
> 
> 
>  Mike> problem and it's a start. I'd just like a convenient way to get
>  Mike> at that information (or is there a better way?).
> 
> Not that I know of. If there is and it is as light an intrusion as
> /var/lib/lxc/${VM}/path/to/PID_file would be, am for it too.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100201/ca058502/attachment.pgp>