qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Network bridging without adding bridge with brctl, poss


From: Jan Kiszka
Subject: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible?
Date: Sun, 20 Feb 2011 10:44:13 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-02-19 20:32, Gerhard Wiesinger wrote:
> Hello,
> 
> I like the way like VMWare Server 2.x does bridging: There is no need to
> change basic network interface settings and add a bridge between the
> existing network interface like e.g. discussed in:
> http://www.linux-kvm.com/content/using-bridged-networking-virt-manager
> 
> VMWare Server 2.x does the following:
> 1.) Add vmnet network interfaces with vmnet.tar code (should be GPL v2).
> 2.) Starting a user mode process which I guess does the forwarding:
> /usr/bin/vmnet-bridge
> /usr/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid -n 0 -i eth0
> 3.) 2 other processes:
> /usr/bin/vmnet-netifup -d /var/run/vmnet-netifup-vmnet1.pid /dev/vmnet1
> vmnet1
> /usr/bin/vmnet-dhcpd -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf
> /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf
> /var/run/vmnet-dhcpd-vmnet1.pid vmnet1
> 
> /usr/bin/vmnet-bridge
> Either the '-n' or '-p' option must be given exactly once.
> Usage: vmnet-bridge (-n<number> | -p<uuid>) [-d<file name>]
> [(-e<interface> | -i<interface>)] [-s<number>] [-h]
>        -i<interface> include interface
>        -e<interface> exclude interface
>        -g            prefer default gateway interface
>        -n<number>    virtual network
>        -p<uuid>      private virtual network
>        -d<file name> process identifier file name
>        -s<number>    optional pipe descriptor for service to send
>                      a two byte startup status code
>        -h            help
> 
> Might this also be easily possible with QEMU/KVM?
> What do you thing about this? Worth to implement?
> Any other suggestions to achieve this?

http://virt.kernelnewbies.org/MacVTap

Enabling host<->guest communication this way is still a bit unhandy
IMHO. You need a fairly recent iproute2 version, then set up macvtap
like this

    ip link add link eth1 name macvtap0 type macvtap mode bridge

And you additionally seem to need a separate macvlan device attached to
that bridge, configured to the IP of the host.

    ip link add link eth1 name macvlan0 type macvlan mode bridge
    ifconfig macvlan0 ...

Not sure if this is by design or due to internals of the networking
stack, but it looks unintuitive from user perspective. Maybe Arnd can
shed a light on this.

Of course, you could also simply offload all that setup to libvirt.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]