Hi Edison, On Fri, Feb 1, 2013 at 2:30 PM, Edison Su <edison...@citrix.com> wrote:
> SSVM is unnecessary for LXC, AFAICT. The template can be directly > downloaded to primary storage through LXC host. **** > > Here is what will happen in the new storage framework:**** > > Register template: if there is no nfs secondary storage specified, mgt > server just put template url into vm_template db.**** > > Primarystoragedownload: mgt server will send down template url to LXC > host, agent will download template into primary storage. > The new storage framework sounds like a nice optimization. System vm is one thing(we get rid of it), but how about router VM? Router > VM is used not only for DNS/DHCP, but also for egress/ingress control, load > balancer etc. Do you know, inside LXC container, can you set iptables > rules? If it’s not, then we need a way to workaround router VM. > I just tested out a couple simple iptable rules from inside an lxc container. Seems to work fine for me. > **** > > I am thinking about, always using KVM to start system VM, so that you > don’t need to build LXC system VM template. I assume, both LXC and KVM can > co-exist on the same host(they should, but never try it by myself). If it’s > true, you can reuse KVM system vm templates for LXC. > Interesting, this kind of changes the model to supporting multiple hypervisors at the host level. Let's chat more offline about this on Tuesday. Thanks, -Phong > > **** > > ** ** > > *From:* Phong Nguyen [mailto:pngu...@gilt.com] > *Sent:* Thursday, January 31, 2013 7:20 PM > > *To:* cloudstack-dev@incubator.apache.org > *Cc:* Edison Su > *Subject:* Re: Adding LXC support to Cloudstack**** > > ** ** > > 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.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**** > > ** ** >
