On 04/18/2011 02:58 PM, Arnd Bergmann wrote:
> On Monday 18 April 2011, Asias He wrote:
>>
>> Hi, folks
>>
>> I am trying to use qemu/qemu-kvm with macvtap using following commands:
>>
>> # ip link add link eth0 name v0 type macvtap mode {vepa,bridge,private}
>> # ip link set v0 address da:4e:17:88:42:b1 up
>> # idx=`ip link show v0 | grep mtu| awk -F":" '{print $1}'`
>> # kvm -net nic,macaddr=da:4e:17:88:42:b1 -net tap,fd=3 -hda
>> /home/asias/qemu-stuff/sid.img 3<>/dev/tap${idx}
>>
>> I found that guest can access other hosts on the LAN except the host
>> where guest lives, and host where guest lives can not access guest.
>>
>> My question is: Does macvtap support host(hypervisor host) to guest
>> communication?
>>
>
> You can communicate between macvtap and macvlan devices when they are in
> bridge mode, but these devices cannot communicate with clients that
> run on the underlying device.
>
> Just add a macvlan device to your hardware interface and use that in
> the host instead of running on the low-level device directly.
Hi, Arnd
Works for me now. Thanks!
Here are some thoughts on the macvtap:
(1) Is it possible to add an interface to macvtap like /dev/net/tun,
eg, /dev/net/macvtap. Currently, it is hard to use macvtap programmatically.
(2) Adding another macvlan device(e.g., macvlan0) to the hardware
interface(e.g., eth0) and using it as the old eth0 make the process of
using macvtap complicate. One has to reconfigure the network. This is
not optimal from the user perspective. Is it possible to leave the
low-level device as is when using the macvtap device?
>
> The other option is to use a vepa enabled bridge, but these are relatively
> rare.
>
> Arnd
>
--
Best Regards,
Asias He
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
