[Netkit.users] VDE & Netkit

[Massimo Rimondini]

Dear Antonio,

Antonio Anselmi wrote:

>hello virtual networkers, pleased to meet you again ....especially Massimo
>Riondini by Netkit team !
>  
>
Here I am! A loud hello to you too! :)

>I use VDE in order to connect two or many virtual switches who belong to
>remote host. Is not important which "socket" is used by the switches, UML's
>machines (the same for Netkit) can connect themselves to a classic
>uml-switch or to a vde switch whith any kind of problem.
>  
>
OK, I see both kinds of switches use UNIX sockets. Hence, the UML kernel 
won't notice the difference at all.

>You can setup a (virtual) lan and make several v-machines using the UML
>command line int. or using the Netkit "vstart" and joining the machines to
>vde switches with a small change in the command (case of UML) or in the
>script vstart (case of Netkit); then you can obtain a large network (on the
>same broadcast domain) joining all the vde switches by dpipe and vde_plug
>(as you can see at www.blogin.it/uml-vde-r.htm).
>
>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 ;)

>The matter is the possibility to make a "large" virtual network using
>Netkit/UML and VDE together: machines by Netkit - interconnectivity by VDE.
>The Netkit team could improve his switch ...but the job is just ready (this
>is my opinion).
>  
>
Taking advantage of already available tools is surely a benefit. But, in 
what sense do you say the job is ready? Are you speaking about 
configurable packet delay/loss/reordering and similar stuff? I suppose 
all this can be implemented via VDE by using real network connections 
or, in a scenario in which all UML machines run on a single host, by 
using ad-hoc packet schedulers.
Anyway, I think equipping *_switches with the capability to emulate this 
results in simpler and more flexible configuration of the virtual network.

>Concerning a large virtual network (...of virtual machines) we need
>differents IP address belonging to the same net: this is a problem because
>people lives in different place and *unawares* can assign duplicated IP
>address to their virtual machines! Sure, people should configure only MAC
>address for their inerfaces and the net should provide a DHCP service.
>Logically, each  MAC address also must be unique in the net ...
>  
>
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!). But this would only become 
useful if a (very) large number of users chooses to run "steady" virtual 
machines. I might be wrong, but I'm not sure this is an issue to be 
concerned with yet. Maybe in the future...

>Speaking about DHCP ...I'm thinking to spend some day with slirpvde ...whath
>do you think about it ?
>  
>
I've never been using it. Hence, I cannot give you a meaningful opinion 
about whether using slirpvde is a good idea or not.

>Speaking about MAC ...I think to obtain a randomized MAC address during vm
>setup (maybe using netkit-phase1 script) rather than a "manual"
>configuration ...in order to avoid duplicated ones!
>  
>
Mmmhhh... not sure this is a good idea. I understand it works well with 
small networks, but since the problem actually arises with (very) large 
networks, the risk of conflicts is still there.

>Hopening I have been clear ...
>  
>
You have. Hope I have too. :)

>Antonio
>  
>
Bye,
Massimo.