Re: [Qemu-devel] tun/tap networking: patch for existing tun

[Jean-Christian de Rivaz]

Jim C. Brown a écrit :

> > The idea of the "-vde" option is to have in parameter the VDE socket 
> > (default to "/tmp/vde.ctl") an act like vde_plug so it don't need any 
> > other code to work. Just start a "vde_switch" and as many "qemu -vde" 
> > you wants to create a complete virtual nework (1 switch and n hosts).
>
> One potential issue is that the vde code is under the GPL, while qemu (at
> least the part that we're talking about) is under the BSD license.

Ok. that a point to look at. The methode used to connect to a VDE is 
simple, and it should be relatively a small work to rewrite a new code 
that do that under the BSD license.


> I'm not sure if use of VDE is common enough to justify having special code for
> it in qemu anyways.

It's matter to make the use of VDE easy for the users. I think it will 
become more common that some others options for advancer users. Product 
like vmware offert a private network setting in standard.


> > I think that a syntax like "-net type[:macaddr][,arg[,arg[...]]]" is 
> > more usefull, since the MAC addresse of the TAP devices is not alway 
> > specified as it can be set randomly by the Linux kernel (with possible 
> > collision see code in include/linux/etherdevice.h).
>
> The macaddr sets the mac address of the guest nic that qemu provides. I do
> not know if it is possible to set a tap device's mac address on creation
> but if it is possible then I agree that it would be a useful parameter.

From Linux drivers/net/tun.c

static int tun_chr_ioctl(struct inode *inode, struct file *file,
                         unsigned int cmd, unsigned long arg)
{
[...]
        case SIOCSIFHWADDR:
                /** Set the character device's hardware address. This 
is used when
                 * filtering packets being sent from the network device 
to the character
                 * device. */
                memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data,
                                min(sizeof ifr.ifr_hwaddr.sa_data, 
sizeof tun->dev_addr));
                DBG(KERN_DEBUG "%s: set hardware address: 
%x:%x:%x:%x:%x:%x\n",
                                tun->dev->name,
                                tun->dev_addr[0], tun->dev_addr[1], 
tun->dev_addr[2],
                                tun->dev_addr[3], tun->dev_addr[4], 
tun->dev_addr[5]);
                return 0;

Giving this code, I think the answare is yes: it's possible to set the 
MAC addresse of a TUN/TAP device.


> > In case of this new interface, will network script still needed. If yes, 
> > how should we handle them in the new option syntax ?
>
> Network scripts will only be needed for tuntap devices that are created by
> qemu, same as now. The "-n script" thing (defaulting to /etc/qemu-ifup) should
> continue to work fine.
>
> The parameters that we choose to pass to the script will be a separate issue.
> My vote is qemu-ifup tapname macaddr (with macaddr being what was specified
> on the -net command line or the appropriate default).

Ok.


> > The fact that we don't know what Fabrice think about this subjet is a 
> > problem. Only Fabrice can commit to the qemu CVS as I understand. I hope 
> > Fabrice read this list and can provids to us usefull informations on how 
> > to make the patch to get it accepted.
>
> Actually a lot of the issues have been discussed before. The -net syntax was
> his idea I believe. Once Fabrice makes his opinion known, he generally will
> keep quiet until code appears.
>
> Once the patch is written, then we can start asking Fabrice for changes or
> improvements needed to make the patch commitable (as then we'll actually have
> something substantial for him to look at).

Ok. I havn't read all the posts into this maling list, but I hope the 
indications you provids are the conclusion of what has been discussed 
before.

--
Jean-Christian de Rivaz