[EMAIL PROTECTED] 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
