On Wed, Aug 15, 2007 at 10:35:28AM -0600, Bruce Evans wrote: Not sure if you've come across the screenshots ... http://virt-manager.org/screenshots/networking.html In the UI we refer to two concepts 'Virtual network' - this is the NAT based networking using the APIs above 'Shared physical device' - this is bridging a guest directly to LAN Not entirely sure what you mean by client vs server related. The APIs are basically for defining a virtual network on a host (aka Dom0). You can then connect a guest to the virtual network by using guest XML that looks like <interface type="network"> <source network="default"/> </interface> The original design/concept doc is http://www.gnome.org/~markmc/virtual-networking.html The high level concept for virtual networks is that they provide a means to connect guests to the network without having to bridge them to the LAN. This is primarily to handle the laptop use case - Often disconnected from both wired & wireless - guests should be able to communicate to hosts & between each other regardless - The active network device can change on-the-fly - eg NetworkManager switching wired, to wireless. If a device is active, the guests should be able to reach the internet via the device in question. - The active device is not neccessarily 802.11 based - eg ppp, or VPN so can not bridge guests directly to physical device. So to satisfy these requirements a virtual network is defined to consist of: - An isolated bridge device with no physical devices attached - Device is configured with an IP address. At this time, usually from one of the IPv4 private ranges. - Optionally a daemon on the host provides DHCP addresses from one or more IP ranges. - Optionally the network can be configured to allow traffic to outside world using NAT. It may be restricted to only traffic to a specific physical device. The virtual network is not Xen or QEMU specific - you can mix & match the guests you connect to a virtual network on a single host, so allowing a Xen guest to talk to a QEMU guest. So, in terms of connecting a Xen guest to the virtual network, this works in just the same way as regular Xen briding - we still use vif-bridge for this task. For QEMU guests, we use tun/tap devices. There is no connectivity from off-host into the guests - this is obviously a result of NAT. We're basically providing a managed equivalent of Xen's network-nat/vif-nat. We may consider allowing a proxy_arp routed config for virtual networks instead of NAT in the future, but that's TBD (this would be closer to the Xen's scripts network-route/vif-route). For DHCP + DNS services we provide the dnsmasq daemon which binds to the bridge device associated with the virtual network. NB there can be many virtual networks each with their own bridge device & DHCP/DNS daemon on each host. On Linux we use 'brctl' & a couple of Linux ioctl()'s for setting up the bridges. This obviously needs an alternate impl for Solaris. The code is all well isolated in src/bridge.c On Linux we use iptables for seting up the NAT rules, so again an alternate impl is needed for Solaris. The code is is src/iptables.c (bad name really I guess). Finally there is defined to be one virtual network 'out of the box' called 'default'. This is configured with 192.168.122.0/255.255.255.0, and does NAT to the outside world. This ensures that a base install will always have a means to connect a guest to the network. So the two core pieces I think you'd need to look at are the bridge.c file and the iptables.c file, providing impls for Solaris. Most of the rest of the networking code shouldn't have any serious portability problems. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|