Looks like good progress. Although it looks like KVM and LXC share a lot, I wouldn't modify the kvm plugin, but rather extract out some common bits into a LibvirtAgentBase or something like that. And then create a new LXC plugin based off of that.
+Edison, Wido, Marcus, Kelven, Donal for more suggestions As far as system vms go, I think you've got some good ideas there. On 1/31/13 7:20 PM, "Phong Nguyen" <pngu...@gilt.com> wrote: >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+Clou >dstack > >Thanks, >Phong > > >On Thu, Jan 31, 2013 at 4:44 PM, Chiradeep Vittal < >chiradeep.vit...@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" <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 >> >>