On Tue, Jun 17, 2008 at 4:48 PM, Matthew Farrellee <mfarrellee@redhat.com> wrote:
Renato Figueiredo wrote:
It's great to see this project getting off the ground!

Our group is very interested in this idea. We have been working with
wide-area VM appliance Condor pools for a couple of years and have developed
a peer-to-peer virtual network (IP-over-P2P, or IPOP) that supports
decentralized NAT traversal with techniques including hole-punching and
proxying. We've found this to be very useful to facilitate the deployment of
ad-hoc wide-area Condor pools/flocks where nodes are increasingly behind
NATs. The IPOP code is also open source and user level (though it currently
uses a tap device), so I thought this would be of interest to the list. Here
are some pointers for more information (and software):

http://grid-appliance.org
http://ipop-project.org

We're starting a collaboration with the Condor group on a particular
application of this virtual infrastructure for computer architecture
simulation (http://archer-project.org); hopefully sharing our experience
with this system can benefit nightlife and vice-versa.

Bests,
--rf

Renato,

IPOP is definitely something that could be of use to the Nightlife project. Letting NAT'd execution nodes join the network is currently an issue. As Nightlife grows it could also become a good testbed for IPOP.

Have you considered packaging IPOP in Fedora?

Best,


matt

Matt,

Currently we distribute the source code and a binary snapshot. As far as creating a Fedora package, that shouldn't be difficult at all - the only dependences we have are the mono C# runtime, the dhcp client, and a tap device.

The other issue is configuration of virtual IP addresses. That would be a function of how nightlife is expected to be deployed - e.g. a single big pool or many smaller pools.  We typically use a private address space for the tap endpoints and that is within NATed virtual machines -  avoiding conflicts with the host network. If the tap device is connected directly to a host, it's important to configure the tap to avoid overlapping private network address spaces. We can deal with multiple decoupled IP overlays through IPOP namespaces, but that assumes multiple Condor pools - a node would join only a pool for an IP range that doesn't conflict with their private networks.

One idea we have thought about in the context of Condor but have not implemented is port forwarding instead of IP tunneling, which would not require a tap device. This requires some more development, unfortunately we haven't had the cycles to pull this off yet.

Bests,
--rf

--
Dr. Renato J. Figueiredo
Associate Professor
ACIS Lab / Electrical and Computer Engineering
University of Florida
http://byron.acis.ufl.edu
ph: 352-392-6430