cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phong Nguyen <pngu...@gilt.com>
Subject Re: Adding LXC support to Cloudstack
Date Fri, 01 Feb 2013 03:20:01 GMT
Hi Chiradeep,

I've checked in initial code that is able to spin up an LXC container from
the Cloudstack UI. I could definitely use some review on this and if I'm
doing anything majorly wrong, it would be good to know sooner ;)

In development, I used your recommendation and ran the
NfsSecondaryStorageResource on my laptop to test and debug code for
downloading templates. Worked great and easier than trying to keep dual KVM
+ LXC in development.

My full test setup right now involves a management server + KVM + LXC. I'm
using the KVM host to run the System VMs. After the SSVM spins up, I log in
and swap out the cloud jars to run my dev code. I'm also using the KVM
router VM for dhcp and dns.

How should we handle the System VMs? Does it make sense to create a System
VM for LXC?

I have updated the wiki page with more details:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Support+in+Cloudstack

Thanks,
Phong


On Thu, Jan 31, 2013 at 4:44 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:

> Any updates / help?
>
> I'd like to point out that the secondary storage process
> (NfsSecondaryStorageResource) can run outside a system vm as well (bare
> metal).
> It has a "inSystemVm" flag that turns on/off various things.
>
> Alternatively you can run LocalSecondaryStorageResource instead -- this
> executes inside the management server and expects the NFS server to be
> mounted on the management server.
> But not all features are supported (esp. zone-to-zone copy).
>
> With the storage refactor, you may not even need either resource as long
> as all you need is to copy images to primary storage from some store
> (e.g., a web server).
>
>
> On 1/8/13 4:42 PM, "Alex Karasulu" <akarasulu@apache.org> wrote:
>
> >On Wed, Jan 9, 2013 at 1:25 AM, Phong Nguyen <pnguyen@gilt.com> wrote:
> >
> >> Thank you all for your responses.
> >>
> >> Chip: I have started a design document and will keep it updated with our
> >> discussions.
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Support+in+Clo
> >>udstack
> >>
> >> Chiradeep: I think option #2 as you have suggested is a good idea. I'll
> >>be
> >> looking at this part soon in my dev setup, thanks for the advice.
> >>
> >> Alex: Would be great to work with you if you are interested.
> >>
> >>
> >Yes, I'll contact you offline for minor coordination details and every so
> >often we can report back to the mailing list.
> >
> >
> >> In terms of collaborating, since I'm a non-committer, would the best
> >>option
> >> be to develop on github? I'm assuming branch commit privileges is only
> >>for
> >> committers?
> >>
> >
> >Yep but with git it makes little difference.
> >
> >
> >> Thanks,
> >> -Phong
> >>
> >>
> >> On Tue, Jan 8, 2013 at 1:47 AM, Chiradeep Vittal <
> >> Chiradeep.Vittal@citrix.com> wrote:
> >>
> >> >
> >> >
> >> > 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.
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Best Regards,
> >-- Alex
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message