incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: Adding LXC support to Cloudstack
Date Tue, 08 Jan 2013 06:47:22 GMT


On 1/7/13 1:17 PM, "Alex Karasulu" <akarasulu@apache.org> wrote:

>On Mon, Jan 7, 2013 at 11:15 PM, Alex Karasulu <akarasulu@apache.org>
>wrote:
>
>>
>>
>>
>> On Mon, Jan 7, 2013 at 11:13 PM, Alex Karasulu
>><akarasulu@apache.org>wrote:
>>
>>> Hi Phong,
>>>
>>> On Mon, Jan 7, 2013 at 10:02 PM, Phong Nguyen <pnguyen@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.


Mime
View raw message