Fwd: Setup of xlxc

[rahul kumar]

FYI

---------- Forwarded message ----------
From: Aryaman Gupta <aryama...@research.iiit.ac.in>
Date: Sun, May 10, 2015 at 2:24 AM
Subject: Setup of xlxc
To: rahul kumar <discover...@gmail.com>


Hey,

I am writing this mail to give you updates on setting up xlxc on my pc.
I have installed XIA kernel using instructions at https://github.com/AltraMayor/XIA-for-Linux/wiki/How-to-install. While creating container a variable 'XLXC' in xlxc-create.rb is uninitialized, which stops from setup of container.

Thanks,
Aryaman Gupta

[Aryaman Gupta]

FIxed

[Cody Doucette]

Hi Aryaman,

I'm glad you resolved the issue. As you may know, the outcome of your project can be submitted for inclusion in the main XLXC repository. However, if you find smaller bugs or issues, you can submit patches along the way as well.

Best,

Cody

On Wed, May 13, 2015 at 7:12 PM, Aryaman Gupta <aryam...@gmail.com> wrote:

FIxed

--
You received this message because you are subscribed to the Google Groups "Linux XIA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-xia+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aryaman Gupta]

Hi,
I wanted to clarify some parts of my project.
As my project involves defining library in Ruby that enables one to describe the topology, I want to know functionality of the library
and how it is different from extending XLXC to support arbitrary topologies.
I believe for extending XLXC to support arbitrary topologies I need to describe topologies for XIA containers using bridge (or OVS) which has been implemented for star and connected in xlxc-net file.
Please help me clear my understanding of above points.

[Michel Machado]

Hi Aryaman,

Extending XLXC to support arbitrary topologies means that you must have functions to start containers, to establish a single link between two containers, to link a group of containers to a single switch, assign the proper information to the protocol stacks of the containers, and boot up all the setup. Notice that these functions are hard to call since they need a lot of very specific parameters to do their work. That is where the library will help.

One could conceive a language to describe an arbitrary topology that would be compiled into calls of the previously mentioned functions. But defining this language and writing its compiler is quite a lot of work. Instead, one can define a library that describe the topology, so the user of this library would use this library to describe the topology it wants. The output of this library is a data structure that is easy to navigate. Thus, one can write the code to navigate this data structure and properly call the functions that will instantiate the containers, links, and switches.

The library will have at least a function to create a node (i.e. a container), a another to create a switch (i.e. OVS), functions to link node with node, and node with switches. These functions are high level, all the details will be figured out by the code that will make the final calls.

How does one navigate the data structure that the library produces? Notice that this data structure is essentially a graph whose nodes and links will have some associated information, so you can start with a depth-first algorithm, and change and/or refine it to as you find necessary.

Given that all the library does is to create an easy to navigate data structure, one can now write another function that receives this data structure and generates a yEd file. And all one needs to export from RocketFuel is to read RocketFuel data format and generate call to our library. That is, once everything is done, we will be able to visualize RocketFuel's topologies in yEd and simulate them in XLXC!

--