incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Zhang <Frank.Zh...@citrix.com>
Subject RE: Adding LXC support to Cloudstack
Date Thu, 31 Jan 2013 22:11:06 GMT
A out of topic question.
Is LXC preferred by most hosting company than KVM/XEN? Looks like it's performance is better

> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Thursday, January 31, 2013 1:45 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Edison Su
> Subject: Re: Adding LXC support to Cloudstack
> 
> 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
View raw message