[Libvir] libvirt & vde_switch

In reply to http://www.redhat.com/archives/libvir-list/2007-April/msg00177.html an area where vde_switch support is usefull is an unprivileged user running tests. A test suite involving the creation of qemu instances thru libvirt should not be forced to create a bridge or alter the iptables configuration. With vde_switch and slirpvde multiple qemu instances can be run without altering the network configuration of the host. I hope it helps. Cheers

On Tue, Feb 05, 2008 at 12:53:57AM +0100, Loic Dachary wrote:
In reply to
http://www.redhat.com/archives/libvir-list/2007-April/msg00177.html
an area where vde_switch support is usefull is an unprivileged user running tests. A test suite involving the creation of qemu instances thru libvirt should not be forced to create a bridge or alter the iptables configuration. With vde_switch and slirpvde multiple qemu instances can be run without altering the network configuration of the host.
When Mark originally investigated & designed the virtual networking APIs in libvirt he looked at VDE as one of the possible impls http://www.gnome.org/~markmc/virtual-networking.html VDE could certainly serve as an impl of the virtual networking APIs for non-root users whom do not have ability to create bridge devices. In the end we only implemented the bridge/iptables based driver for networking, but the libvirt driver design means it is possible to drop in an alternate impl of the networking APIs as required. So if someone's interested in writing a driver using VDE patches are welcomed.... The main problem I know of is not VDE itself, but the means of connecting a VDE network to the outside world - namely the SLIRP code. Last time it was examined it was found to be non-64-bit clean & have significant question around security. We wondered about whether it would be possible to have a privileged helper for creating tap devices which could be used to connect the VDE network to the outside world. Its possible, but the devil's in the details & how you constrain access to not conflict with host networking. 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 -=|

On Tue, 2008-02-05 at 00:25 +0000, Daniel P. Berrange wrote:
The main problem I know of is not VDE itself, but the means of connecting a VDE network to the outside world - namely the SLIRP code. Last time it was examined it was found to be non-64-bit clean & have significant question around security. We wondered about whether it would be possible to have a privileged helper for creating tap devices which could be used to connect the VDE network to the outside world. Its possible, but the devil's in the details & how you constrain access to not conflict with host networking.
Nice summary ... that's exactly it. The sound part of VDE is it's ability to behave as a userspace ethernet bridge. The nasty part is its TCP/IP stack - which is equivalent to "qemu -net user". The ideal situation would be to allow unprivileged processes use the kernel network stack rather than implementing a whole new stack. We knocked around some ideas on that front but didn't come to any concrete conclusions. Cheers, Mark.
participants (3)
-
Daniel P. Berrange
-
Loic Dachary
-
Mark McLoughlin