incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Adding LXC support to Cloudstack
Date Fri, 01 Feb 2013 10:23:59 GMT
Hi Chiradeep,


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

> Any updates / help?
>
>
Just as an update Phong has made some progress creating LXC based virtual
machines via the libvirt interface. I myself have not caught up to him,
just started stepping through code to see how it would work.

We have weekly meetings on Tuesdays just to see where we are. I'll see
about getting a formal update to the list by then.


> 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.
>
>
This is good to know. I know Phong and I both had some questions about
storage matters.


> 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).
>
>
>
Thanks for the heads up and offer to help. After meeting with Phong next
week we'll report back to the list.

Regards,
Alex


> 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
>
>


-- 
Best Regards,
-- Alex

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