incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: Adding LXC support to Cloudstack
Date Fri, 01 Feb 2013 19:30:54 GMT
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.
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 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.

From: Phong Nguyen [mailto:pnguyen@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.Vittal@citrix.com<mailto:Chiradeep.Vittal@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" <akarasulu@apache.org<mailto:akarasulu@apache.org>>
wrote:

>On Wed, Jan 9, 2013 at 1:25 AM, Phong Nguyen <pnguyen@gilt.com<mailto: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<mailto:Chiradeep.Vittal@citrix.com>> wrote:
>>
>> >
>> >
>> > On 1/7/13 1:17 PM, "Alex Karasulu" <akarasulu@apache.org<mailto:akarasulu@apache.org>>
wrote:
>> >
>> > >On Mon, Jan 7, 2013 at 11:15 PM, Alex Karasulu <akarasulu@apache.org<mailto:akarasulu@apache.org>>
>> > >wrote:
>> > >
>> > >>
>> > >>
>> > >>
>> > >> On Mon, Jan 7, 2013 at 11:13 PM, Alex Karasulu
>> > >><akarasulu@apache.org<mailto:akarasulu@apache.org>>wrote:
>> > >>
>> > >>> Hi Phong,
>> > >>>
>> > >>> On Mon, Jan 7, 2013 at 10:02 PM, Phong Nguyen <pnguyen@gilt.com<mailto: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message