[Netkit.users] VDE & Netkit

[Massimo Rimondini]

Hello Antonio, Marco & everybody in the list.

Performing some planned experiments with VDE would be very interesting.
Anyway, IMHO setting up a wide stable VDNetwork (with a centralized 
resource assignment service, etc.) is a promising idea, but is still 
premature.

I believe we should start with a simple coordinate experience. We may 
exchange details about timings and resources (IPs, ports, accounts, 
etc.) by using our private mails (I know yours, you know mine). If you 
agree, I think this is the best way to go (at least, for now).

Goodbye,
Massimo.


Antonio Anselmi wrote:

>Hello everybody! spring is coming .....and job still remains!
>
>----- Original Message -----
>From: "Massimo Rimondini" <rimondin a dia.uniroma3.it>
>To: <netkit.users a dia.uniroma3.it>
>Sent: Tuesday, April 26, 2005 6:27 PM
>Subject: Re: [Netkit.users] VDE & Netkit
>
>  
>
>>Antonio Anselmi wrote:
>>
>>    
>>
>[snip]
>  
>
>>>Maybe we can think to a particular option, recognised by the vstart,
>>>      
>>>
>which
>  
>
>>>permits to commute betwen uml_switch or vde_switch ...
>>>      
>>>
>
>  
>
>>That's exactly what I have been thinking about. Currently, users can
>>configure the physical network topology based on the "metaphor" of
>>collision domains: every uml_switch corresponds to a collision domain,
>>and interfaces are attached to these "virtual hubs". A possible future
>>scenario is the one in which all the switches are vde_switch'es, and
>>users can optionally choose to attach an interface to a "remote"
>>collision domain (something like: --eth0=192.168.161.3:dom_A), provided
>>that they have an account on the remote machine.
>>Of course, this would only support basic usage of the VDE architecture,
>>but it's just a very preliminary idea. And, you know: the more the
>>flexibility, the less the user friendliness ;)
>>    
>>
>
>yes indeed Massimo! let me talk about this idea ....
>*I'll be a little bit descriptive for people in this list who don't know
>vde*
>
>V-clients who want share a collision domain located on a remote host have to
>open a secure tunnel and run dpipe inside it, plugging in two vde-plugs at
>the sides of
>the tunnel:
>
>dpipe vde_plug <channel> <our_socket> = ssh <remote_machine> vde_plug
><channel>  <remote_socket>
>
>Obviously, users must know the couple "socket name-channel" at their
>disposal on the other side (other than an account): in other words, the
>remote master host must divulge a kind of a "well-know port number" (socket
>name-channel) for the inbound vde connections.
>Makink the right thing, the remote master host should also notice the
>clients about their reserved IP-MAC address to use too! (no DHCP at present
>time).
>The remote master host may mantain a kind of /etc/virtual-hosts as this:
>
>- vm's physical IP source address
>- virtual MAC and IP assigned
>- socket and channel assigned
>- nick name assigned
>
>The second and the last filelds may be shareable among the users (by eMail
>...like the beginning times!).
>In this scenario, as well understood, an ordinary account is no more
>sufficient: this is to say that an user needs distinct "accounting packet"
>for every remote host to connect, consisting in:
>
>- remote host routable address (or its FQDN)
>- username and password
>- name of remote socket and relative channel number
>- IP-MAC address assigned
>- nick name (not necessary)
>
>This "accounting packet" mey be autenticated matching the correspondent line
>in /etc/virtual-hosts.
>
>  
>
>>You appear to be considering a very large scenario. I guess the only way
>>to ensure MAC addresses are unique would be to request them from a
>>(centralized?) service (think about a "virtual provider" that assigns
>>IP/MAC addresses - of course, for free!).
>>    
>>
>
>I appreciate this idea ...a good idea indeed! Read me: we really can begin
>some experiences about what I have wrote above.
>What I propose is this:
>dia uniroma3 act as  the above remote-master-host, who:
>
>- publish the name of the socket assigned to its vde_switch
>- assign channel number, MAC and (non routable) IP address for every virtual
>machine wo want share  the switch
>- assign an ordinary account for ssh (maybe by traditional mail...)
>- establish a period of time in witch the connection are possible (08-10 AM,
>for example)
>
>So we realize the "virtual square" as introduced by Renzo Davoli -
>University of Bologna - coder and mantainer for vde (Marco Fiscato can
>cantact him).
>In another way (due to possible security problems at dia uniroma3) everyone
>may post to each user (who asked for) its own parameters "Hello guy: this is
>may IP for ssh, this is your account, channel and socket name. You must
>introduce your vm to my switch with this IP and MAC. Remember, the
>connection remains open from 3 to 5 PM ! have fun)".
>
>THINK: we all in this list have the opportunity to realize a nice virtual
>"wide collision domain"  where make experiences connecting our own virtual
>machines (UML, netkit, qemu,...), we can set-up a virtual segment inside
>internet which appears and disappears ...(better than old napster!).
>
>As Lennon  ..."you may say I am a dreamer" , but I think this scenario is
>not a futuristic one, I think this is within easy reach of us.
>
>What is the opinion of dia uniroma3 ?
>I can offer the above info in order to realize a vde-connection to my
>switch, anyone can do the same ?
>Let me know your suggestions, comments, ideas  ....
>
>Bye,
>Antonio
>
>P.S.
>
>  
>
>>Anyway, I think equipping *_switches with the capability to emulate this
>>results in simpler and more flexible configuration of the virtual network.
>>
>>    
>>
>Ok Massimo, you're in the right side! the "job" was reffered to a pure and
>simpy switch!
>
>_______________________________________________
>Netkit.users mailing list
>Netkit.users a pop.dia.uniroma3.it
>http://pop.dia.uniroma3.it/mailman/listinfo/netkit.users
>  
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://list.dia.uniroma3.it/mailman/private/netkit.users/attachments/20050504/d5f4101b/attachment.html