Hi,
On Wed, Jun 11, 2008 at 12:36:59PM +0200, zhengda wrote: > [EMAIL PROTECTED] wrote: >> On Sat, Jun 07, 2008 at 10:12:21PM +0200, zhengda wrote: >>> If pfinet can open the interface with device_open(), I think we >>> need to write another program like boot to give pfinet the >>> pseudo master device port and help pfinet open the virtual >>> network interface. >> >> Why another program? I'm pretty sure "boot" is the right place to >> handle this. > > Yes. we can modify "boot" to let pfinet connect to the virtual network > interface created by the hypervisor. but we also want the pfinet > servers to use the hypervisor. If the hypervisor provides the virtual > network interface, we have to find a way to give the pfinet server a > pseudo master device port, so the pfinet server can call device_open() > to connect to the virtual network interface. That is what I was > thinking about. but how do we give the pfinet server running in the > main hurd the pseudo master device port? As you said, the pfinet > server gets the master device port from the proc server. It can work > in subhurd because the proc server in subhurd can give a pseudo > master device port which actually connect to "boot". but it should be > more tricky in the main hurd if we don't modify the code of pfinet > because the pfinet server always gets the real master device port to > the kernel. 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... >>> The second question is: who can create the virtual network >>> interface? >> >> By default, the user who invokes the hypervisor. (I.e. the one >> running "boot".) [...] > It seems you expect several hypervisors can run at the same time and > every user can run his own hypervisor. but I thought only root could > run the hypervisor. The reason is that the hypervisor should be able > to access the network interface. 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... All of these variants have certain merits in different situations, and I think we should support all of them. > and I think we only need one hypervisor running in the system in most > cases, because we want that pfinet servers can communicate with each > other and it's one main function of the hypervisor. It's possible > that one set of pfinet servers connect to one hypervisor and another > set of pfinet servers connects to another hypervisor. In this case, > the pfinet server can only communicate with the one in the same set. I realize now that the actual hypervisor (filtering) functionality is quite orthogonal from the routing (hub) functionality -- either can be useful on its own... You could have one or more filters running on top of a hub to restrict the actual pfinets, or you could have the pfinets directly connect to the hub if you don't need the filtering, or you could use filters alone without any routing between pfinets. The more I think of it, the more I'm convinced that it would actually make most sense to implement the filtering and the routing functionalities in independant translators. It should simplify things and increase flexibility a lot. > But the question is how the hypervisor does the check. It will be much > work if we want the hypervisor understands all packets. 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 :-) 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... With the modular approach, it will be much simpler: Each hypervisor (filter) will provide exactly one virtual interface, and no routing. A hub can be used explicitely to connect several hypervisors. > 3. How does the routing work? it can always work if the packet is > broadcasted to any pfinet servers that connect to the hypervisor. > then pfinet servers can filter packets in the IP layer. but it > cannot give a good performance and there may be a security problem: > every user can see others' packets. A simple hub would always forward to all clients. Filters between the hub and the actual clients can enforce security if necessary. On Sat, Jun 14, 2008 at 06:06:40PM +0200, zhengda wrote: > 1. One solution is that the hypervisor broadcasts a packet to every > pfinet server, as I said before. > 2. The hypervisor can always track which packet is from which virtual > network interface. and a table can be built to record which interface > has what IP. It sends a packet to the interface who owns the > destination IP. > The first solution can be seen as a hub, and the second one as a > switch. The nice thing obout the modular approach is that you can use a simple hub, or if this doesn't suffice for some reason, implement a switch or even a true router... > An acceptable solution (at least for me) can be: when a virtual > network interface is created, a network address must be bound with > it, so the hypervisor can know where to send the packet. I think this variant could be considered a router? I think it would overlap with the functionality of filters though, destroying the modularity... > The user should also tell the hypervisor what is the network address > of the external network, so the hypervisor can know when to send the > packet to the external network. It's reasonable to do that because the > real network interface also connects to the network with a fixed > network address. I don't understand. Each pfinet has a static address, and it needs to be an address valid and distinct in the external network, if this pfinet is ever to communicate over the external network. So how would you use that to distinguish packets to send to the external network?... (It should be possible to set up NAT between the external and virtual network, but I guess that's not what you were thinking about... :-) ) The simple hub probably should just forward all packets to the external interface just as to all other clients. (If there is an external interface at all -- after all, we might set up a purely virtual network...) In fact, the external interface need not be treated different in any way from the other clients, I think. But again, more sophisticated variants can be built if necessary :-) -antrik-
