Re: GSoC: the plan for the project network virtualization

[zhengda]

olafBuddenhagen@gmx.net wrote:
> Indeed, I was thinking only about subhurds here... You are perfectly
> right that if we want to be able to use the hypervisor for pfinets
> running in the same Hurd instance as the hypervisor, we need some method
> to make the pfinets connect to the virtual interface provided by the
> hypervisor instead of the real interface.
>
> One way to achieve this is to modify pfinet so it can connect to an
> explicitely provided device instead of trying to open the kernel device
> directly through the device master port.
>
> The other way is to provide a proxy for the device master port by
> overriding the proc server -- either using a full-blown proc only for
> the pfinet (kind of a micro-subhurd), or a proxy proc that only diverts
> the device master port, and forwards all other requests to the real
> proc...
>
> I'm not sure which is easier to implement. (It's kind of a
> para-virtualization vs. full virtualization question again...) Modifying
> pfinet might be more pargmatical; but replacing proc is certainly more
> interesting -- this kind of partial subhurd-like environments is
> precisely the direction I'd like to explore...
>   
I already modified the pfinet to connect the hypervisor.
I did it just for testing the hypervisor.
I'm creating the proxy of the process server. Hopefully, it's not too 
difficult.
> Well, root could delegate access to the real network interface, so the
> user could run a hypervisor. Or root could run a hypervisor himself,
> giving the user access only to one IP address. Or root could even use
> the hypervisor to give the user access to a range of IP addresses, and
> the user could run another hypervisor to control individual IPs...
>   
"root could delegate access to the real network interface, and the user 
could run a hypervisor"?
How do we do it? create another program that is run by root and that 
communicates with the hypervisor?
Maybe we can do like this:
the user is allowed to run a hypervisor but the hypervisor cannot access 
the network interface.
If the user want to access the external network, his hypervisor must 
forward the packet to the root's hypervisor.
The root's hypervisor is responsible to control the traffic from the user.
The user can do whatever he wants in his hypervisor.
> I don't think there is a need to understand all packets -- in most
> cases, a simple IP-based filter should be sufficient. But of course, you
> could employ other filters if necessary. The modular approach suggested
> above makes this easy :-)
>   
Maybe BPF can also work for this case.
> On Fri, Jun 13, 2008 at 10:59:13PM +0200, zhengda wrote:
>
>   
> >   1. How many pfinet servers are allowed to connect to one hypervisor?
> >   If only one pfinet server is allowed to connect to one hypervisor,
> >   hypervisors must communicate with each other to route packets sent
> >   by pfinet servers. If several pfinet servers are allowed to connect
> >   to the same hypervisor, a hypervisor can route packets inside
> >   itself. If so, does the hypervisor only route the packet among
> >   pfinet servers that connect to the hypervisor? If several pfinet
> >   servers are allowed to connect to the same hypervisor, it's better
> >   for the hypervisor to create multiple virtual network interfaces and
> >   each pfinet server can attach to one interface.
> >     
>
> The original idea was that the hypervisor can create multiple virtual
> interfaces with different filter rules, *and* several pfinets can
> connect to the same virtual interface if desired. (Just as several
> pfinets can connect to the same real interface.) This would have made
> for a rather complicated setup...
>   
I don't think it can complicate the setup if several pfinets connect to 
the same virtual interface at the same time.
The filter behind the virtual interface (suppose there is) only needs 
one rule that checks whether the source address of a packet has the 
right network address.
The pfinet server with the wrong IP address certainly cannot work.


the hypervisor with one virtual interface vs. with multiple virtual 
interface:
If a hypervisor has only one virtual interface, several hypervisors are 
needed to setup, and the packets received by one hypervisor should be 
forwarded to others. Every hypervisor can have a filter to control the 
traffic.
If a hypervisor has several virtual interfaces which can be created by 
the user, one hypervisor can be used to create a network. In this case, 
the packets received from one interface should be forwarded to other 
interfaces, and every interface should have its own filter running 
behind it. If the hypervisor can forwarded to all other hypervisors 
which connect to it (actually, it is really necessary), we can also 
create the hypervisor network just as the hypervisor with one virtual 
interface does (the hypervisor with only one interface can be its 
special case). So we can leave the choice of how they create the network 
to users.
Actually, the hypervisor with multiple virtual interfaces can also be 
thought as the optimization of the one with one interface because the 
performance can be much improved (many copies of packets can be avoided).
The hypervisor with multiple virtual interfaces also needs to forward 
other hypervisors because the hypervisor run by the user cannot access 
the real network interface. It needs to forward the packet to the 
hypervisor run by root first.
I think the hypervisor with multiple interfaces is more flexible. The 
user can run his own hypervisors and creates as many interfaces on them 
as he wants and creates whatever network he wants.

Best,
Zheng Da