On 1/7/13 1:17 PM, "Alex Karasulu" <akaras...@apache.org> wrote:
>On Mon, Jan 7, 2013 at 11:15 PM, Alex Karasulu <akaras...@apache.org> >wrote: > >> >> >> >> On Mon, Jan 7, 2013 at 11:13 PM, Alex Karasulu >><akaras...@apache.org>wrote: >> >>> Hi Phong, >>> >>> On Mon, Jan 7, 2013 at 10:02 PM, Phong Nguyen <pngu...@gilt.com> wrote: >>> >>>> Hi, >>>> >>>> We are interested in adding LXC support to Cloudstack. >>> >>> >>> I've also been interested in Cloudstack support for LXC. I checked a >>>few >>> days ago for it and was disappointed when I could not find it but found >>> support for it in OpenStack instead :P. I wanted to inquire about >>>adding >>> LXC support thinking this might be a good starting point for my getting >>> involved in the code. At this point, I have nothing further to >>>contribute >>> besides the link you already found, but I thought if others saw more >>>people >>> interested then LXC support might be considered. >>> >>> >> Here's a bit more chatter on this topic but as we see it's not been >> implemented. Rip for the picking ... >> >> http://goo.gl/x60At >> >> >s/Rip/Ripe/ damn autocorrect on pad. > > >> >> >>> I've searched around >>>> for container support for Cloudstack and was able to find one posting >>>> related to OpenVZ (over a year ago): >>>> >>>> http://sourceforge.net/mailarchive/message.php?msg_id=28030821 >>>> >>> >>> BTW OpenVZ is great stuff but I've found the fact that you need a >>>custom >>> Kernel a bit of a problem. LXC is much better in this sense since it's >>> already present in every kernel past 2.6.26 (or 2.6.29?) but that's >>>besides >>> the point of this thread. Sorry for digressing. >>> >>> Is there any current, on-going, or future work planned in this area? >>>Are >>>> there any architectural changes since then that would affect the >>>> suggestions in this posting? Any other suggestions greatly >>>>appreciated. >>>> >>>> >>> I too am interested in these details. >>> >>> Thanks, >>> Alex >>> I like the concept of more hypervisors being supported! Having said that, the most perplexing thing that stumps people on such a quest is the need to have a system vm image for the new hypervisor There's a couple of approaches for this 1. Assume a multi-hypervisor zone with enough XS/KVM/VMWare hypervisors to run the standard system vm image 2. Make the system vm optional. This requires some code changes (not major) - make the console proxy optional - run the secondary storage daemon on baremetal (next to the management server) Option #2 will suffice for running vms without complex network services.