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" <akaras...@apache.org> wrote: >On Wed, Jan 9, 2013 at 1:25 AM, Phong Nguyen <pngu...@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.vit...@citrix.com> wrote: >> >> > >> > >> > 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. >> > >> > >> > > > >-- >Best Regards, >-- Alex
