VKernel progress update - 10 Jan 2006

[Matthew Dillon]

:Now vke(4) will have same unit as the backend tap(4), i.e. if you
:specify only -I /dev/tap1 then vke1 will appear, instead of vke0.
:This can make bridge configuration in real kernel less confusion.
:
:Patch is at:
:http://leaf.dragonflybsd.org/~sephe/vke_multi.diff
:
:If no objection comes, it will be committed tomorrow.
:
:Best Regards,
:sephe

    I would suggest that VKE's be numbered from zero, because then we could
    have the vkernel automatically allocate a free TAP interface and not
    create confusion with rc.conf in the virtual environment.

    Also, the vkernel can ifconfig up the TAP side of the interface as well
    or do the basic bridge tie-in.  That way the sysop wouldn't have to
    worry about which tap interface was allocated.

    Bridging is easy mode but not paricularly efficient because broadcasts
    would wind up being spammed to all the running vkernels (not fun!).
    routing a LAN IP might be a better solution.  I can see a need for both
    solutions.

    So, e.g. leave the -I option intact but add some features and optional
    real-kernel-side IP configuration.  like this:

    -I auto:10.0.0.1:10.0.0.2
    -I auto:10.0.0.1:10.0.0.2:24
    -I auto:bridge0
    -I tap0:bridge0

       auto 	   - automatically find a free TAP interface and use it
       10.0.0.1	   - specify TAP interface IP
       10.0.0.2    - specify VKE interface IP
       24          - specify CIDR bits for TAP/BKE (e.g. would be 10.0.0.0/24)
		     if not specified a /30 would be used.

       bridgeN	   - instead of specifying IPs, just tie the TAP interface
		     into the specified bridge. 

		     (we have to make sure that disconnecting the TAP also
		     disconnects it from the bridge)

    What do you think?

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>