[Qemu-devel] tun/tap networking

[Qemu-devel] tun/tap networking

[Don Kitchen]

I'm very pleased with qemu's price/performance ratio.

I've used that one "pricey" product at work, but it always seemed a bit
expensive for home users. But I only knew about some of the other emulators,
the ones that are so slow you wonder why didn't they warn you not to
bother downloading the thing to start with. But qemu has definately made
it past usability barrier.

I have some questions about the networking that I hope someone can answer.
Qemu is able to use tun & tap devices. I've taken the tundev.c program,
which opens a tun device and passes the fd to qemu, and compared it to
the tapdev.c program (which qemu is also able to use) and there's very
little difference to how it's opened. According to the little tun/tap
documentation I understand, the tap descriptor should be providing
ethernet frames instead of the IP packets [ethernet payloads] that tun
should be providing. But qemu does not seem to differentiate between the
two types of file descriptors passed by tundev and tapdev respectively,
so I am a little confused how qemu can work with both types of fd's.

I'm interested in the handling of ethernet frames because I haven't been
able to get the bridge to pass packets between added interfaces (yes,
they're all up and promisc) and I'm not too thrilled with networking being
bridged anyway, and it seems to me that if an fd were hooked up to a
BPF capturing everything from the real ethernet device in promiscuous
mode, and pushing out any raw frames it receives, that I could bypass
the bridge and make it as if the emulator's virtual ethernet device is
a real one. Or is there some reason this won't work? (after all, other
products don't have this, there must be a reason right?)

Thanks

Re: [Qemu-devel] tun/tap networking

[Henrik Nordstrom]

On Fri, 30 Sep 2005, Don Kitchen wrote:

> I have some questions about the networking that I hope someone can answer.
> Qemu is able to use tun & tap devices. I've taken the tundev.c program,
> which opens a tun device and passes the fd to qemu, and compared it to
> the tapdev.c program (which qemu is also able to use) and there's very
> little difference to how it's opened. According to the little tun/tap
> documentation I understand, the tap descriptor should be providing
> ethernet frames instead of the IP packets [ethernet payloads] that tun
> should be providing. But qemu does not seem to differentiate between the
> two types of file descriptors passed by tundev and tapdev respectively,
> so I am a little confused how qemu can work with both types of fd's.

Both are TAP type devices, just using different device drivers in the host 
kernel (tundev uses the new TUN/TAP driver, tapdev uses the obsolete TAP 
driver)

> I'm interested in the handling of ethernet frames because I haven't been
> able to get the bridge to pass packets between added interfaces (yes,
> they're all up and promisc) and I'm not too thrilled with networking being
> bridged anyway, and it seems to me that if an fd were hooked up to a
> BPF capturing everything from the real ethernet device in promiscuous
> mode, and pushing out any raw frames it receives, that I could bypass
> the bridge and make it as if the emulator's virtual ethernet device is
> a real one. Or is there some reason this won't work? (after all, other
> products don't have this, there must be a reason right?)

Look for vde_pcap. Does exacly this (via vde, but trivial to modify to be 
used much in the same manner as tundev). The problem is that you can't 
talk to the host itself using this technique, only the LAN the host is 
connected to.

bridgeing is the best setup if you want QEMU to be able to reach both the 
LAN and the host as if it was another station on the same LAN, but 
requires a bit of reconfiguring of the host to set things up.. (but not 
much).

Regards
Henrik

Re: [Qemu-devel] tun/tap networking

[Paul Brook]

> I have some questions about the networking that I hope someone can answer.
> Qemu is able to use tun & tap devices. I've taken the tundev.c program,
> which opens a tun device and passes the fd to qemu, and compared it to
> the tapdev.c program (which qemu is also able to use) and there's very
> little difference to how it's opened. According to the little tun/tap
> documentation I understand, the tap descriptor should be providing
> ethernet frames instead of the IP packets [ethernet payloads] that tun
> should be providing. But qemu does not seem to differentiate between the
> two types of file descriptors passed by tundev and tapdev respectively,
> so I am a little confused how qemu can work with both types of fd's.

Qemu only uses tap devices (ie. ethernet frames).

> I'm interested in the handling of ethernet frames because I haven't been
> able to get the bridge to pass packets between added interfaces (yes,
> they're all up and promisc) and I'm not too thrilled with networking being
> bridged anyway, and it seems to me that if an fd were hooked up to a
> BPF capturing everything from the real ethernet device in promiscuous
> mode, and pushing out any raw frames it receives, that I could bypass
> the bridge and make it as if the emulator's virtual ethernet device is
> a real one. Or is there some reason this won't work? (after all, other
> products don't have this, there must be a reason right?)

The host doesn't see the packets set with BFP.

Paul

Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
> I've used that one "pricey" product at work, but it always seemed a bit
> expensive for home users. But I only knew about some of the other emulators,
> the ones that are so slow you wonder why didn't they warn you not to
> bother downloading the thing to start with. But qemu has definately made
> it past usability barrier.
> 

Because qemu is not an emulator per se, it is properly called a dynamic
translator.

(It's a distinction that many will quarrel over for a long time. ;)

> I have some questions about the networking that I hope someone can answer.
> Qemu is able to use tun & tap devices. I've taken the tundev.c program,
> which opens a tun device and passes the fd to qemu, and compared it to
> the tapdev.c program (which qemu is also able to use) and there's very
> little difference to how it's opened. According to the little tun/tap
> documentation I understand, the tap descriptor should be providing
> ethernet frames instead of the IP packets [ethernet payloads] that tun
> should be providing. But qemu does not seem to differentiate between the
> two types of file descriptors passed by tundev and tapdev respectively,
> so I am a little confused how qemu can work with both types of fd's.
> 

I am confused as well. Are you sure that tundev.c creates a tun device? Or
is it creating a tap device that is named tun0?

Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (ethernet
frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP frames).

qemu breaks those rules and calls the tap device that it creates tun0. This is
done for reasons that Fabrice has not made clear. (I assume there is a reason
for it because he has refused to apply any of the patches that fix this.)

qemu has no support for true tun devices. It only deals with ethernet frames,
so it only works with tap devices. You can tell because a tap device is
opened when you add a special flag, IFF_TAP, to the ifr_flags of the TUNSETIFF
ioctl call.

> I'm interested in the handling of ethernet frames because I haven't been
> able to get the bridge to pass packets between added interfaces (yes,
> they're all up and promisc) and I'm not too thrilled with networking being
> bridged anyway,

Do you mean the kernel bridge, br0? Or are you talking about some sort of
user space bridge, like bridged (which uses a series of packet sockets to
bridge between multiple ethernet (ethX) devices) ?

> and it seems to me that if an fd were hooked up to a
> BPF capturing everything from the real ethernet device in promiscuous
> mode, and pushing out any raw frames it receives, that I could bypass
> the bridge and make it as if the emulator's virtual ethernet device is
> a real one. Or is there some reason this won't work? (after all, other
> products don't have this, there must be a reason right?)

Ah, you're talking about using a packet socket, right?

That works fine for the most part. There is one thing that you have missed
though: guest->host communication doesn't work when you do that.

When you push out a raw frame, it leaves the real ethernet device before the
host sees it. So guest->host doesn't work. You need to find another way to
send packets from the guest to the host. Most host OSes will not let you
do this at all. (Windows seems to be the exception, winpcap's pcap_sendpacket()
appears to work fine for that job.)

VMware gets around this by using its kernel module: when the guest sends something
to the host, VMware passes the packet to its kernel module, which injects it
into the incoming packet stream. Without your own kernel module though, you
can't do this.

> 
> Thanks
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] tun/tap networking

[Jean-Christian de Rivaz]

Jim C. Brown a écrit :

> Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (ethernet
> frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP frames).
> 
> qemu breaks those rules and calls the tap device that it creates tun0. This is
> done for reasons that Fabrice has not made clear. (I assume there is a reason
> for it because he has refused to apply any of the patches that fix this.)

You point the real question: why it has been impossible to get accepted 
any patch that fixed this. I has proposed one myself and I get no 
comment at all. I see similar effort from others and obviousely there 
failed almost the same way. No getting any valuable comment about why a 
idea proposed by many peopoles is not applyed make this subject very hard.

I hope that we can resolve this subject, because in my point of view, 
using a existing "tun" is far more simpler than create one the way quemu 
do; and this open a lot of new uses in terme of the network managment of 
the quemu instance. The very first one for me is to allow only root to 
setup a DHCP server and to assign "tuns" interfaces to the users that 
needs it, so there don't even have to think about the network setup, 
ther just boot into quemu an OS with a DHCP client.

Any comment this time ?
-- 
Jean-Christian de Rivaz

Re: [Qemu-devel] tun/tap networking

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim C. Brown schrieb:
> On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
> 
[...]
> 
>>I'm interested in the handling of ethernet frames because I haven't been
>>able to get the bridge to pass packets between added interfaces (yes,
>>they're all up and promisc) and I'm not too thrilled with networking being
>>bridged anyway,
> 
> 
> Do you mean the kernel bridge, br0? Or are you talking about some sort of
> user space bridge, like bridged (which uses a series of packet sockets to
> bridge between multiple ethernet (ethX) devices) ?
> 
> 
>>and it seems to me that if an fd were hooked up to a
>>BPF capturing everything from the real ethernet device in promiscuous
>>mode, and pushing out any raw frames it receives, that I could bypass
>>the bridge and make it as if the emulator's virtual ethernet device is
>>a real one. Or is there some reason this won't work? (after all, other
>>products don't have this, there must be a reason right?)
> 
> 
> Ah, you're talking about using a packet socket, right?
> 
> That works fine for the most part. There is one thing that you have missed
> though: guest->host communication doesn't work when you do that.
> 
> When you push out a raw frame, it leaves the real ethernet device before the
> host sees it. So guest->host doesn't work. You need to find another way to
> send packets from the guest to the host. Most host OSes will not let you
> do this at all. (Windows seems to be the exception, winpcap's pcap_sendpacket()
> appears to work fine for that job.)
> 

That means it would work if the host NIC is connected to a switch? Then
the switch would send packets from the guest which are meant for the
host back to the host NIC and everything's fine! Or did I misunderstand
that now?

Regards,
Oliver Gerlich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDPnM2TFOM6DcNJ6cRAlTaAJ9gxN9CUnSEeKl5lPbURTEh33Rl8QCgpmNV
cUuiGGOkpPVYxzeo9ZoksWM=
=tEkV
-----END PGP SIGNATURE-----

Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> That means it would work if the host NIC is connected to a switch? Then
> the switch would send packets from the guest which are meant for the
> host back to the host NIC and everything's fine! Or did I misunderstand
> that now?
> 
> Regards,
> Oliver Gerlich

If the switch sends packets from the host NIC back to itself, I believe that
would work.

If you have 2 nics on the host computer connected to the same hub, that will
also work (one nic can receive the guest packets sent out from the other nic).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Sat, Oct 01, 2005 at 10:12:41AM +0200, Jean-Christian de Rivaz wrote:
> Jim C. Brown a ?crit :
> 
> >Typically, tapX (tap0, tap1, etc) names are reserved for tap devices 
> >(ethernet
> >frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP 
> >frames).
> >
> >qemu breaks those rules and calls the tap device that it creates tun0. 
> >This is
> >done for reasons that Fabrice has not made clear. (I assume there is a 
> >reason
> >for it because he has refused to apply any of the patches that fix this.)
> 
> You point the real question: why it has been impossible to get accepted 
> any patch that fixed this. I has proposed one myself and I get no 
> comment at all. I see similar effort from others and obviousely there 
> failed almost the same way. No getting any valuable comment about why a 
> idea proposed by many peopoles is not applyed make this subject very hard.
> 

The change I was talking about is a one line patch...

It's annoying that Fabrice has said nothing about it. But it doesn't actually
mess anything up, it's just confusing for advanced users.

I presume that the device qemu makes is called tun0 because Fabrice wants to
make clear that he doesnt use (and wont support) the ethertap device. Not a
very good reason.

(Or maybe he wants to keep it tun0 because if he changed the name he'd have
to change the option -tun-fd to -tap-fd and that'd break some scripts.)

> I hope that we can resolve this subject, because in my point of view, 
> using a existing "tun" is far more simpler than create one the way quemu 
> do;

I never mentioned that. At all.

And qemu already supports that, via the -tun-fd option.

> and this open a lot of new uses in terme of the network managment of 
> the quemu instance. The very first one for me is to allow only root to 
> setup a DHCP server and to assign "tuns" interfaces to the users that 
> needs it, so there don't even have to think about the network setup, 
> ther just boot into quemu an OS with a DHCP client.
> 

That is a little tricky to do - but qemu can do it.

> Any comment this time ?
> -- 
> Jean-Christian de Rivaz
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] tun/tap networking

[Paul Brook]

On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > That means it would work if the host NIC is connected to a switch? Then
> > the switch would send packets from the guest which are meant for the
> > host back to the host NIC and everything's fine! Or did I misunderstand
> > that now?
>
> If the switch sends packets from the host NIC back to itself, I believe
> that would work.

A switch will not send a packet back where it came from. That would be a sure 
way to introduce infinite forwarding loops.

Paul

Re: [Qemu-devel] tun/tap networking

[Henrik Nordstrom]

On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:

> You point the real question: why it has been impossible to get accepted any 
> patch that fixed this. I has proposed one myself and I get no comment at all. 
> I see similar effort from others and obviousely there failed almost the same 
> way. No getting any valuable comment about why a idea proposed by many 
> peopoles is not applyed make this subject very hard.

I think it is in part due to the command line parsing of network 
parameters being all crap and need to be replaced by something more sane.

> I hope that we can resolve this subject, because in my point of view, using a 
> existing "tun" is far more simpler than create one the way quemu do

I agree that persistent tun tap devices is much easier to work with.

Regards
Henrik

Re: [Qemu-devel] tun/tap networking

[Henrik Nordstrom]

On Sat, 1 Oct 2005, Oliver Gerlich wrote:

> That means it would work if the host NIC is connected to a switch? Then
> the switch would send packets from the guest which are meant for the
> host back to the host NIC and everything's fine! Or did I misunderstand
> that now?

In this kind of setup you will need two NICs in the host for this to work. 
One NIC used by the guest, the other by the host.  If you have more than 
one guest and wants the guests to be able to talk to each other then you 
basically need one NIC per guest.

Just being connected to a switch does not help as switched (and even hubs) 
does not bounce packets back on the same port they came from.

Regards
Henrik

Re: [Qemu-devel] tun/tap networking

[Jean-Christian de Rivaz]

>>You point the real question: why it has been impossible to get accepted 
>>any patch that fixed this. I has proposed one myself and I get no 
>>comment at all. I see similar effort from others and obviousely there 
>>failed almost the same way. No getting any valuable comment about why a 
>>idea proposed by many peopoles is not applyed make this subject very hard.
>>
> 
> 
> The change I was talking about is a one line patch...
> 
> It's annoying that Fabrice has said nothing about it. But it doesn't actually
> mess anything up, it's just confusing for advanced users.
> 
> I presume that the device qemu makes is called tun0 because Fabrice wants to
> make clear that he doesnt use (and wont support) the ethertap device. Not a
> very good reason.
> 
> (Or maybe he wants to keep it tun0 because if he changed the name he'd have
> to change the option -tun-fd to -tap-fd and that'd break some scripts.)
> 
> 
>>I hope that we can resolve this subject, because in my point of view, 
>>using a existing "tun" is far more simpler than create one the way quemu 
>>do;
> 
> 
> I never mentioned that. At all.

Agree. Sorry, I extented the subjet beyon the initial subjet of this thread.

> And qemu already supports that, via the -tun-fd option.

Can you please give me an exemple how to use the -tun-fd option to open 
an existing tun (i.e: tun-alice) ? This option only work for already 
opened tap/tun interface as I understand.

> 
>>and this open a lot of new uses in terme of the network managment of 
>>the quemu instance. The very first one for me is to allow only root to 
>>setup a DHCP server and to assign "tuns" interfaces to the users that 
>>needs it, so there don't even have to think about the network setup, 
>>ther just boot into quemu an OS with a DHCP client.
>>
> 
> 
> That is a little tricky to do - but qemu can do it.

The problem is exactly because this is tricky! Simply telling quemu to 
use a existing tun and boot a OS with a DHCP client is the simplest 
operation you can imagine to allow testing network experiment. Network 
setup is the job of root. Users just use the setup and that must be dead 
simple.

Regards,
-- 
Jean-Christian de Rivaz

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

[Jean-Christian de Rivaz]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Attached is a patch proposition to allow opennig an existing tun 
(already configured by root).

This patch can work only on Linux as it make no change into the code for 
BSD.

Please make open comment about this to improve it or to let my know why 
this if not a good thing...
-- 
Jean-Christian de Rivaz

[-- Attachment #2: tun2.patch --]
[-- Type: text/x-patch, Size: 5680 bytes --]

Index: qemu-doc.texi
===================================================================
RCS file: /cvsroot/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.65
diff -u -r1.65 qemu-doc.texi
--- qemu-doc.texi	28 Jul 2005 22:27:28 -0000	1.65
+++ qemu-doc.texi	1 Oct 2005 20:38:16 -0000
@@ -222,6 +222,22 @@
 aa:bb:cc:dd:ee:ff in hexa). The mac address is incremented for each
 new network interface.
 
+@item -tun devname
+Try to use @var{devname} while opening a tap/tun host network interface and use
+it. If it work, the network init script is not executed for this
+interface. If it don't work, the interface will use the name assigned
+by the operating system and the network init script is executed.
+
+This option permit the use of preconfigured interface. For example, as
+root you can assign a tun interface to a user and configure it like this:
+@example
+tunctl -u bob -t tun2
+ifconfig tun2 192.168.2.1
+@end example
+Then bob can use this interface with the option "-tun tun2". Note that
+option permit the use of a DHCP server on the host to configure the
+guest interface.
+
 @item -tun-fd fd
 Assumes @var{fd} talks to a tap/tun host network interface and use
 it. Read @url{http://bellard.org/qemu/tetrinet.html} to have an
Index: vl.c
===================================================================
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.136
diff -u -r1.136 vl.c
--- vl.c	3 Sep 2005 21:33:43 -0000	1.136
+++ vl.c	1 Oct 2005 20:38:17 -0000
@@ -1663,7 +1663,7 @@
     }
     memset(&ifr, 0, sizeof(ifr));
     ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
-    pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
+    pstrcpy(ifr.ifr_name, IFNAMSIZ, (ifname && *ifname) ? ifname : "tun%d");
     ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
     if (ret != 0) {
         fprintf(stderr, "warning: could not configure /dev/net/tun: no virtual network emulation\n");
@@ -1689,7 +1689,7 @@
     qemu_add_fd_read_handler(nd->fd, fd_can_read, fd_read, opaque);
 }
 
-static int net_tun_init(NetDriverState *nd)
+static int net_tun_init(NetDriverState *nd, int script)
 {
     int pid, status;
     char *args[3];
@@ -1700,7 +1700,7 @@
         return -1;
 
     /* try to launch network init script */
-    pid = fork();
+    pid = script ? fork() : -1;
     if (pid >= 0) {
         if (pid == 0) {
             parg = args;
@@ -2851,6 +2851,7 @@
            "-nics n         simulate 'n' network cards [default=1]\n"
            "-macaddr addr   set the mac address of the first interface\n"
            "-n script       set tap/tun network init script [default=%s]\n"
+           "-tun devname    try to use devname while opening tap/tun interface\n"
            "-tun-fd fd      use this fd as already opened tap/tun interface\n"
 #ifdef CONFIG_SLIRP
            "-user-net       use user mode network stack [default if no tap/tun script]\n"
@@ -2940,6 +2941,7 @@
     QEMU_OPTION_nics,
     QEMU_OPTION_macaddr,
     QEMU_OPTION_n,
+    QEMU_OPTION_tun,
     QEMU_OPTION_tun_fd,
     QEMU_OPTION_user_net,
     QEMU_OPTION_tftp,
@@ -3003,6 +3005,7 @@
     { "nics", HAS_ARG, QEMU_OPTION_nics},
     { "macaddr", HAS_ARG, QEMU_OPTION_macaddr},
     { "n", HAS_ARG, QEMU_OPTION_n },
+    { "tun", HAS_ARG, QEMU_OPTION_tun },
     { "tun-fd", HAS_ARG, QEMU_OPTION_tun_fd },
 #ifdef CONFIG_SLIRP
     { "user-net", 0, QEMU_OPTION_user_net },
@@ -3136,7 +3139,7 @@
     int cyls, heads, secs, translation;
     int start_emulation = 1;
     uint8_t macaddr[6];
-    int net_if_type, nb_tun_fds, tun_fds[MAX_NICS];
+    int net_if_type, nb_tun, nb_tun_fds, cnt_tun_fds, tun_fds[MAX_NICS];
     int optind;
     const char *r, *optarg;
     CharDriverState *monitor_hd;
@@ -3190,7 +3193,12 @@
         parallel_devices[i][0] = '\0';
     parallel_device_index = 0;
     
+    for(i = 0; i < MAX_NICS; i++) {
+	nd_table[i].ifname[0] = '\0';
+    }
+    nb_tun = 0;
     nb_tun_fds = 0;
+    cnt_tun_fds = 0;
     net_if_type = -1;
     nb_nics = 1;
     /* default mac address of the first network interface */
@@ -3313,18 +3321,25 @@
             case QEMU_OPTION_append:
                 kernel_cmdline = optarg;
                 break;
+	    case QEMU_OPTION_tun:
+		net_if_type = NET_IF_TUN;
+		if (nb_tun+nb_tun_fds < MAX_NICS) {
+		    pstrcpy(nd_table[nb_tun++].ifname, IFNAMSIZ, optarg);
+		}
+		break;
 	    case QEMU_OPTION_tun_fd:
                 {
                     const char *p;
                     int fd;
                     net_if_type = NET_IF_TUN;
-                    if (nb_tun_fds < MAX_NICS) {
+                    if (nb_tun+nb_tun_fds < MAX_NICS) {
                         fd = strtol(optarg, (char **)&p, 0);
                         if (*p != '\0') {
                             fprintf(stderr, "qemu: invalid fd for network interface %d\n", nb_tun_fds);
                             exit(1);
                         }
                         tun_fds[nb_tun_fds++] = fd;
+			nb_tun++;
                     }
                 }
 		break;
@@ -3603,12 +3618,20 @@
 #endif
 #if !defined(_WIN32)
         case NET_IF_TUN:
-            if (i < nb_tun_fds) {
-                net_fd_init(nd, tun_fds[i]);
-            } else {
-                if (net_tun_init(nd) < 0)
-                    net_dummy_init(nd);
-            }
+	    if (nd->ifname && *(nd->ifname)) {
+		if (net_tun_init(nd, 0) < 0) {
+		    nd->ifname[0] = '\0';
+		    if (net_tun_init(nd, 1) < 0)
+		      net_dummy_init(nd);
+		}
+	    } else {
+		if (cnt_tun_fds < nb_tun_fds) {
+		    net_fd_init(nd, tun_fds[cnt_tun_fds++]);
+		} else {
+		    if (net_tun_init(nd, 1) < 0)
+		      net_dummy_init(nd);
+		}
+	    }
             break;
 #endif
         case NET_IF_DUMMY:

Re: [Qemu-devel] tun/tap networking

[Jean-Christian de Rivaz]

Henrik Nordstrom a écrit :
> On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
> 
>> You point the real question: why it has been impossible to get 
>> accepted any patch that fixed this. I has proposed one myself and I 
>> get no comment at all. I see similar effort from others and obviousely 
>> there failed almost the same way. No getting any valuable comment 
>> about why a idea proposed by many peopoles is not applyed make this 
>> subject very hard.
> 
> 
> I think it is in part due to the command line parsing of network 
> parameters being all crap and need to be replaced by something more sane.

Ok. So if the command line parsing of network parameters is crap for 
someone, he is free to improve it. But, sorry, I found that not a valid 
excuse to silently reject others featurs to the network setup. I will be 
very happy to modify the patch I propose to be compliant with a new 
network parameters parsing code.

>> I hope that we can resolve this subject, because in my point of view, 
>> using a existing "tun" is far more simpler than create one the way 
>> quemu do
> 
> 
> I agree that persistent tun tap devices is much easier to work with.

Thanks. :-)
-- 
Jean-Christian de Rivaz

Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
> >And qemu already supports that, via the -tun-fd option.
> 
> Can you please give me an exemple how to use the -tun-fd option to open 
> an existing tun (i.e: tun-alice) ? This option only work for already 
> opened tap/tun interface as I understand.
> 

I see what you mean now. qemu itself has no direct support for persistent tuntap
devices.

However, I imagine that one could modify tundev.c or tapdev.c to open a persistent
tuntap device (by name) and then pass the fd to qemu via -tun-fd. It would be
better if qemu had direct support for them of course.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Sat, Oct 01, 2005 at 02:50:59PM +0100, Paul Brook wrote:
> On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> > On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > > That means it would work if the host NIC is connected to a switch? Then
> > > the switch would send packets from the guest which are meant for the
> > > host back to the host NIC and everything's fine! Or did I misunderstand
> > > that now?
> >
> > If the switch sends packets from the host NIC back to itself, I believe
> > that would work.
> 
> A switch will not send a packet back where it came from. That would be a sure 
> way to introduce infinite forwarding loops.
> 
> Paul
> 

Depends on how intellegent the switch is. (Forwarding back only those packets
which are addressed to the host itself wouldn't necessarily cause an infinite
loop. Tho the switch would probably be smarter if it dropped such packets
outright.)

Of course there are more favorable solutions (2 nics on the same hub, kernel
bridging, even VMware's method), so getting such a switch to work is probably
not worth the time.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] tun/tap networking

[Jean-Christian de Rivaz]

Jim C. Brown a écrit :
> On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
> 
>>>And qemu already supports that, via the -tun-fd option.
>>
>>Can you please give me an exemple how to use the -tun-fd option to open 
>>an existing tun (i.e: tun-alice) ? This option only work for already 
>>opened tap/tun interface as I understand.
>>
> 
> 
> I see what you mean now. qemu itself has no direct support for persistent tuntap
> devices.
> 
> However, I imagine that one could modify tundev.c or tapdev.c to open a persistent
> tuntap device (by name) and then pass the fd to qemu via -tun-fd. It would be
> better if qemu had direct support for them of course.

Where are this tundev.c or tapdev.c files ? I just updated qemu from CVS 
and I found no files named like this.

jcdr@talla:~/qemu/qemu$ cvs -qz9 update -AdP
? tun2.patch
M qemu-doc.texi
M vl.c
jcdr@talla:~/qemu/qemu$ find . -type f -name "t*dev*"
jcdr@talla:~/qemu/qemu$

-- 
Jean-Christian de Rivaz

Re: [Qemu-devel] tun/tap networking

[Henrik Nordstrom]

On Sat, 1 Oct 2005, Jim C. Brown wrote:

> Depends on how intellegent the switch is. (Forwarding back only those packets
> which are addressed to the host itself wouldn't necessarily cause an infinite
> loop. Tho the switch would probably be smarter if it dropped such packets
> outright.)

Imagine having two (or more) such switches in your network... kaboom on 
the first packet sent after a host as expired from the forwarding table on 
one of them...

Regards
Henrik

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

[Henrik Nordstrom]

On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:

> Attached is a patch proposition to allow opennig an existing tun (already 
> configured by root).
>
> This patch can work only on Linux as it make no change into the code for BSD.
>
> Please make open comment about this to improve it or to let my know why this 
> if not a good thing...

Quite similar to my patch posted some many months ago (and reposted some 
week ago on request).

Regards
Henrik

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

[Jean-Christian de Rivaz]

Henrik Nordstrom a écrit :
> On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
> 
>> Attached is a patch proposition to allow opennig an existing tun 
>> (already configured by root).
>>
>> This patch can work only on Linux as it make no change into the code 
>> for BSD.
>>
>> Please make open comment about this to improve it or to let my know 
>> why this if not a good thing...
> 
> 
> Quite similar to my patch posted some many months ago (and reposted some 
> week ago on request).

Yes. This is just an update of my first patch posted the 13 january 2005 
so it should apply without offset warning.

Maybe can I propose to joint our effort ?
-- 
Jean-Christian de Rivaz

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

[Henrik Nordstrom]

On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:

> Yes. This is just an update of my first patch posted the 13 january 2005 so 
> it should apply without offset warning.
>
> Maybe can I propose to joint our effort ?

What remains to make it complete is the command line parser, allowing 
network options to be specified in a reasonable manner. See discussions 
some time ago regarding MAC addresses.

Regards
Henrik

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

[Lars Munch]

On Sun, Oct 02, 2005 at 12:24:53PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
> 
> >Yes. This is just an update of my first patch posted the 13 january 2005 
> >so it should apply without offset warning.
> >
> >Maybe can I propose to joint our effort ?
> 
> What remains to make it complete is the command line parser, allowing 
> network options to be specified in a reasonable manner. See discussions 
> some time ago regarding MAC addresses.
> 
> Regards
> Henrik

The "use existing tun/tap network interface" is is a popular patch to
create. I also did one in november 2004 :-)

http://lists.gnu.org/archive/html/qemu-devel/2004-11/msg00454.html

-- Lars Munch

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

[Jean-Christian de Rivaz]

Lars Munch a écrit :
> On Sun, Oct 02, 2005 at 12:24:53PM +0200, Henrik Nordstrom wrote:
> 
>>On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
>>
>>
>>>Yes. This is just an update of my first patch posted the 13 january 2005 
>>>so it should apply without offset warning.
>>>
>>>Maybe can I propose to joint our effort ?
>>
>>What remains to make it complete is the command line parser, allowing 
>>network options to be specified in a reasonable manner. See discussions 
>>some time ago regarding MAC addresses.
>>
>>Regards
>>Henrik
> 
> 
> The "use existing tun/tap network interface" is is a popular patch to
> create. I also did one in november 2004 :-)
> 
> http://lists.gnu.org/archive/html/qemu-devel/2004-11/msg00454.html

Good to know that (I joined the liste only this year).

It's nice to see that we all have almost the same idea of how to do the 
patch. As I see, there just differ in some details and in how to handle 
the network script.

Is there any guideline about the network script ? Or should we add an 
option to let the choice to the user if the network script is called or 
not ?

-- 
Jean-Christian de Rivaz

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

[Anthony Liguori]

Jean-Christian de Rivaz wrote:

> Henrik Nordstrom a écrit :
>
>> On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
>>
>>> Attached is a patch proposition to allow opennig an existing tun 
>>> (already configured by root).
>>>
>>> This patch can work only on Linux as it make no change into the code 
>>> for BSD.
>>>
>>> Please make open comment about this to improve it or to let my know 
>>> why this if not a good thing...
>>
>>
>>
>> Quite similar to my patch posted some many months ago (and reposted 
>> some week ago on request).
>
>
> Yes. This is just an update of my first patch posted the 13 january 
> 2005 so it should apply without offset warning.

I don't understand, why is this patch needed?

It's a pretty simple C program to create a tun device by whatever name 
you want and just pass the fd to qemu via -tun-fd.  I think it's 
generally better to have the least number of options necessary to make 
things easier to understand.

Is it really something that so many people would want to use that it 
warrants making it an option?  Is there a concrete use-case that this 
enables?

Regards,

Anthony Liguori

> Maybe can I propose to joint our effort ?

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

[Jim C. Brown]

On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote:
> I don't understand, why is this patch needed?
> 

It makes qemu easier to use.

A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1"
instead of hacking around with persistenttapdev.c

> It's a pretty simple C program to create a tun device by whatever name 
> you want and just pass the fd to qemu via -tun-fd.  I think it's 
> generally better to have the least number of options necessary to make 
> things easier to understand.
> 

Like the way vdeq/vdeqemu does it? That works, but is that really the best way
to handle it?

vdeq works the way it does because the odds of getting a special "-vde-socket"
option in qemu were moot. And perhaps so the author of VDE could have control
over what options vdeq supported. (In the case of vdeq, its a clever hack: both
tuntap devices and sockets are controlled via fds, so vdeq sends a socket fd
instead of a tuntap fd and qemu is none the wiser. Hypothetically one could
even pass a regular file via -tun-fd.)

Having an option for specifying tuntap devices by name on the command line
(persistent or not) is the cleanest way to do it, and also the easiest for the
user. Maybe even make it so we just pass an option "-tap tap0": if tap0 doesnt
exist then qemu creates a new device with that name, if it does exist then
qemu opens it as if it were a persistent tuntap.

In fact, if qemu supported both these things, then I don't see a reason for
-tun-fd at all (except for something like VDE).

> Is it really something that so many people would want to use that it 
> warrants making it an option?  Is there a concrete use-case that this 
> enables?

What it really boils down to is cleaning up the command line options for the
network interface(s), which up to now have been added in a hackish, piece-wise
manner.

> 
> Regards,
> 
> Anthony Liguori
> 
> >Maybe can I propose to joint our effort ?
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

On Sun, Oct 02, 2005 at 07:50:29PM +0200, Jean-Christian de Rivaz wrote:
> Is there any guideline about the network script ? Or should we add an 
> option to let the choice to the user if the network script is called or 
> not ?
> 
> -- 
> Jean-Christian de Rivaz
> 

If it's persistent, the device should already have been set up before qemu gets
its hands on it. Same goes for pre-created tuntaps that are passed via -tun-fd.
Only the tap devices that qemu creates need to be set up by qemu, which is the
only case where we have to have the network script.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jean-Christian de Rivaz]

Jim C. Brown a écrit :
> On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote:
> 
>>I don't understand, why is this patch needed?
>>
> 
> 
> It makes qemu easier to use.
> 
> A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1"
> instead of hacking around with persistenttapdev.c

I am happy to see your comment, realy :-)

>>It's a pretty simple C program to create a tun device by whatever name 
>>you want and just pass the fd to qemu via -tun-fd.  I think it's 
>>generally better to have the least number of options necessary to make 
>>things easier to understand.
>>
> 
> 
> Like the way vdeq/vdeqemu does it? That works, but is that really the best way
> to handle it?
> 
> vdeq works the way it does because the odds of getting a special "-vde-socket"
> option in qemu were moot. And perhaps so the author of VDE could have control
> over what options vdeq supported. (In the case of vdeq, its a clever hack: both
> tuntap devices and sockets are controlled via fds, so vdeq sends a socket fd
> instead of a tuntap fd and qemu is none the wiser. Hypothetically one could
> even pass a regular file via -tun-fd.)

VDE is a very useful code to complete project like qemu. It requiere 
special code to connect to the vde_switch, but this not a complexe code 
(see how vde_plug make that). Since VDE is higly likly used with qemu, I 
see a good thing that qemu have ditrectly an -vde option and a -tun 
option. This will corver a large part of real use and still be dead 
simple to understand for the user.

> Having an option for specifying tuntap devices by name on the command line
> (persistent or not) is the cleanest way to do it, and also the easiest for the
> user. Maybe even make it so we just pass an option "-tap tap0": if tap0 doesnt
> exist then qemu creates a new device with that name, if it does exist then
> qemu opens it as if it were a persistent tuntap.

It's already the case with at least my proposed patch. I have't tested 
the patch written by Henrik Nordstrom or Lars Munch but it's likly that 
there work the same way since this feature come from the Linux kernel 
tun code.

> In fact, if qemu supported both these things, then I don't see a reason for
> -tun-fd at all (except for something like VDE).

Agree, and a -vde option will go forward in this direction.

>>Is it really something that so many people would want to use that it 
>>warrants making it an option?  Is there a concrete use-case that this 
>>enables?
> 
> 
> What it really boils down to is cleaning up the command line options for the
> network interface(s), which up to now have been added in a hackish, piece-wise
> manner.

So an open question: is the -tun and -vde options a good idea to cleanup 
the network interface options ? To be clear, I don't propose to remove 
option at this point, but just to make qemu more easy to use for simple 
and most common setup.

-- 
Jean-Christian de Rivaz

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

[Jean-Christian de Rivaz]

Jim C. Brown a écrit :
> On Sun, Oct 02, 2005 at 07:50:29PM +0200, Jean-Christian de Rivaz wrote:
> 
>>Is there any guideline about the network script ? Or should we add an 
>>option to let the choice to the user if the network script is called or 
>>not ?
>>
>>-- 
>>Jean-Christian de Rivaz
>>
> 
> 
> If it's persistent, the device should already have been set up before qemu gets
> its hands on it. Same goes for pre-created tuntaps that are passed via -tun-fd.
> Only the tap devices that qemu creates need to be set up by qemu, which is the
> only case where we have to have the network script.
> 

Thanks a lot for this! :-)

If I haven't make a mistake, this is how my proposed patch work. If it 
don't work that way, please tell me to fix it.

-- 
Jean-Christian de Rivaz

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

[Jim C. Brown]

On Sun, Oct 02, 2005 at 10:23:41PM +0200, Jean-Christian de Rivaz wrote:
> VDE is a very useful code to complete project like qemu. It requiere 
> special code to connect to the vde_switch, but this not a complexe code 
> (see how vde_plug make that). Since VDE is higly likly used with qemu, I 
> see a good thing that qemu have ditrectly an -vde option and a -tun 
> option. This will corver a large part of real use and still be dead 
> simple to understand for the user.
> 

I'd argue that it should be "-tap" or "-tuntap" instead of "-tun", since using
tun would confuse users who knew the distinction between tun devices and tap
devices.

I'm not sure if a "-vde" option is necessary or a good idea, though. We might
want to keep a "-socket-fd" option around for the really technical people who
do funny things like that. (imho "-tun-fd" is badly named since it doesn't
require a tun/tap fd, it works with any type of file descriptor.)

> >Having an option for specifying tuntap devices by name on the command line
> >(persistent or not) is the cleanest way to do it, and also the easiest for 
> >the
> >user. Maybe even make it so we just pass an option "-tap tap0": if tap0 
> >doesnt
> >exist then qemu creates a new device with that name, if it does exist then
> >qemu opens it as if it were a persistent tuntap.
> 
> It's already the case with at least my proposed patch. I have't tested 
> the patch written by Henrik Nordstrom or Lars Munch but it's likly that 
> there work the same way since this feature come from the Linux kernel 
> tun code.
> 

> >In fact, if qemu supported both these things, then I don't see a reason for
> >-tun-fd at all (except for something like VDE).
> 
> Agree, and a -vde option will go forward in this direction.
> 

-tun-fd (or -socket-fd) should probably be kept around for really specialized
applications (and the geeks who know how to use them). We should have options
that adaquately cover everything in normal use, of course.

> >>Is it really something that so many people would want to use that it 
> >>warrants making it an option?  Is there a concrete use-case that this 
> >>enables?
> >
> >
> >What it really boils down to is cleaning up the command line options for 
> >the
> >network interface(s), which up to now have been added in a hackish, 
> >piece-wise
> >manner.
> 
> So an open question: is the -tun and -vde options a good idea to cleanup 
> the network interface options ? To be clear, I don't propose to remove 
> option at this point, but just to make qemu more easy to use for simple 
> and most common setup.
> 

Actually, they might just add to the clutter. -dummy-net, -user-net, -nics,
-macaddr, etc. It would be even worse if not for the fact that Fabrice has
refused to incorporate many networking patches (silently, as usual).

So while we're at it, we should redesign the interface for qemu. For each nic,
we'd have -net type[,macaddr] where type is "tap" or "user" or "dummy" and
the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
would depend on number of -net options, with none meaning either no nics or
one nic defaulting to tap (or user if tap isn't available).

For the tap type we could have a 3rd optional parameter for the name, e.g.
-net tap,macaddr,name (with name defaulting to tapX if its not specified).

> -- 
> Jean-Christian de Rivaz
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jean-Christian de Rivaz]

> I'd argue that it should be "-tap" or "-tuntap" instead of "-tun", since using
> tun would confuse users who knew the distinction between tun devices and tap
> devices.

Ok for "-tuntap" long option. Can I propose "-t" for a short option ?

> I'm not sure if a "-vde" option is necessary or a good idea, though. We might
> want to keep a "-socket-fd" option around for the really technical people who
> do funny things like that. (imho "-tun-fd" is badly named since it doesn't
> require a tun/tap fd, it works with any type of file descriptor.)

So "-tun-fd" will be renamed "-socket-fd".

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).

> -tun-fd (or -socket-fd) should probably be kept around for really specialized
> applications (and the geeks who know how to use them). We should have options
> that adaquately cover everything in normal use, of course.

Yes, this is the good way to make it, I agree.

>>So an open question: is the -tun and -vde options a good idea to cleanup 
>>the network interface options ? To be clear, I don't propose to remove 
>>option at this point, but just to make qemu more easy to use for simple 
>>and most common setup.
> 
> Actually, they might just add to the clutter. -dummy-net, -user-net, -nics,
> -macaddr, etc. It would be even worse if not for the fact that Fabrice has
> refused to incorporate many networking patches (silently, as usual).

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.

> So while we're at it, we should redesign the interface for qemu. For each nic,
> we'd have -net type[,macaddr] where type is "tap" or "user" or "dummy" and
> the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
> would depend on number of -net options, with none meaning either no nics or
> one nic defaulting to tap (or user if tap isn't available).
> 
> For the tap type we could have a 3rd optional parameter for the name, e.g.
> -net tap,macaddr,name (with name defaulting to tapX if its not specified).

This is an other work, but why not ?

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 advantage of your proposition is that it make more easy to add new 
type of network device like VDE. This enable to possibility to use a 
"socket-fd" type to make everyone happy.

In case of this new interface, will network script still needed. If yes, 
how should we handle them in the new option syntax ?

-- 
Jean-Christian de Rivaz

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

[Jim C. Brown]

On Mon, Oct 03, 2005 at 11:46:57AM +0200, Jean-Christian de Rivaz wrote:
> Ok for "-tuntap" long option. Can I propose "-t" for a short option ?
> 

Makes sense.

> 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.

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

> This is an other work, but why not ?
> 
> 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.

> The advantage of your proposition is that it make more easy to add new 
> type of network device like VDE. This enable to possibility to use a 
> "socket-fd" type to make everyone happy.
> 
> 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).

> 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).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Henrik Nordstrom]

On Sun, 2 Oct 2005, Jim C. Brown wrote:

> vdeq works the way it does because the odds of getting a special "-vde-socket"
> option in qemu were moot. And perhaps so the author of VDE could have control
> over what options vdeq supported. (In the case of vdeq, its a clever hack: both
> tuntap devices and sockets are controlled via fds, so vdeq sends a socket fd
> instead of a tuntap fd and qemu is none the wiser. Hypothetically one could
> even pass a regular file via -tun-fd.)

It needs to be a datagram socket, but any kind of datagram socket will do 
fine.

> Having an option for specifying tuntap devices by name on the command line
> (persistent or not) is the cleanest way to do it, and also the easiest for the
> user. Maybe even make it so we just pass an option "-tap tap0": if tap0 doesnt
> exist then qemu creates a new device with that name, if it does exist then
> qemu opens it as if it were a persistent tuntap.

And fits extremely nicely in the command line scheme Fabrice proposed some 
weeks ago.

> In fact, if qemu supported both these things, then I don't see a reason for
> -tun-fd at all (except for something like VDE).

VDE and a number of other similar applications is a fairly strong reason 
to support the -tun-fd functionality I would say.

> What it really boils down to is cleaning up the command line options for the
> network interface(s), which up to now have been added in a hackish, piece-wise
> manner.

And persistent TUN TAP devices makes it extremely clean on the host, and 
as it is not difficult for qemu there is not really any reason why not.

One could obviously drop all the TUN/TAP setup code from qemu, requiring 
the user to wrap qemu in some application passing it already opened 
sockets using -tun-fd, but this will be a bit cumbersome to users.. but on 
the other hand not worse than the users using VDE or similar userspace 
switches/hubs.

Regards
Henrik

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

[Henrik Nordstrom]

On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:

> It's already the case with at least my proposed patch. I have't tested the 
> patch written by Henrik Nordstrom or Lars Munch but it's likly that there 
> work the same way since this feature come from the Linux kernel tun code.

Indeed. It is impossible to support persistent TUN/TAP devices without not 
also supporting dynamically created devices.

>> In fact, if qemu supported both these things, then I don't see a reason for
>> -tun-fd at all (except for something like VDE).
>
> Agree, and a -vde option will go forward in this direction.

vde is not the only userspace switch available. Locking qemu to only vde 
would be bad. I then much prefer not having the builtin vde option or even 
the tun/tap open code and only keep -tun-fd.  (from -tun-fd all the others 
can be implemented by a wrapper opening the connections and handing them 
over to QEMU)

> So an open question: is the -tun and -vde options a good idea to cleanup the 
> network interface options?

No.

> To be clear, I don't propose to remove option at this point, but just to 
> make qemu more easy to use for simple and most common setup.

See the proposal from Fabrice some month ago on what the command line 
parameters should look like. Very nice imho. And very easy to extend with 
new modes (VDE, persistent TUN/TAP, whatever) without having to introduce 
new confusing options.

Regards
Henrik

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

[Henrik Nordstrom]

On Sun, 2 Oct 2005, Jim C. Brown wrote:

> So while we're at it, we should redesign the interface for qemu. For each nic,
> we'd have -net type[,macaddr] where type is "tap" or "user" or "dummy" and
> the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
> would depend on number of -net options, with none meaning either no nics or
> one nic defaulting to tap (or user if tap isn't available).

The proposal by Fabrice looks better to me

-net usernet,macaddr=00:11:a:0:2:19 -net tunfd=10,macaddr=00:11:a:0:1:19

this way the syntax can easily be extended with new options as needed, and 
the exact order of things is not important (you just specify the net 
parameters as needed).

Only objection is that for the tunfd case I would use

   -net tap,fd=10,macaddr=...

> For the tap type we could have a 3rd optional parameter for the name, 
> e.g. -net tap,macaddr,name (with name defaulting to tapX if its not 
> specified).

What about this:

    -net tap,ifname=qemu0,macaddr=...

Regards
Henrik

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

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

[Henrik Nordstrom]

On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote:

> 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).

Or in line with the earlier proposal of a -net option:

   -net vde,socket=/path/to/vde.ctl,group=xxx

where socket defaults to /tmp/vde.ctl and group defaults to 0 if not 
specified.

> 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 MAC of the TUN/TAP device on the host side is a completely different 
thing and is the MAC the HOST should use on that virtual ethernet. What 
the option to QEMU specifies is the MAC QEMU should use.

> In case of this new interface, will network script still needed. If yes, how 
> should we handle them in the new option syntax ?

-net ...,script=/path/to/script

Regards
Henrik

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

[Henrik Nordstrom]

On Mon, 3 Oct 2005, Jim C. Brown wrote:

> 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.

Not really. None of the VDE code is needed to connect to VDE. The protocol 
used for VDE connection management is dead simple.

> 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.

It is, but defenitely overkill for builtin to QEMU. If you need special 
MACs on the host side then use persistent TUN/TAP devices and set the MAC 
from the host side.

If you use dynamic TUN/TAP devices then the script used for configuring 
the host side of the newly created TUN/TAP interface can also set the MAC 
address if desired. This you can do today without changing a single line 
of QEMU.

> 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).

Note: This MAC addr will be the MAC that QEMU is using, not the MAC the 
TUN/TAP device should be configured to. Only use of passing this to the 
script is if your script needs to add firewalling restricting which MACs 
QEMU is allowed to use, but in such case you are most likely better using 
a persistent TUN/TAP device anyway with no need of this script..

Regards
Henrik

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

[Jean-Christian de Rivaz]

Henrik Nordstrom a écrit :
> On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
> 
>> It's already the case with at least my proposed patch. I have't tested 
>> the patch written by Henrik Nordstrom or Lars Munch but it's likly 
>> that there work the same way since this feature come from the Linux 
>> kernel tun code.
> 
> 
> Indeed. It is impossible to support persistent TUN/TAP devices without 
> not also supporting dynamically created devices.

Agree. My patch don't drop the dynamic way to use TUN/TAP! Or it has a 
bug in it.


> vde is not the only userspace switch available. Locking qemu to only vde 
> would be bad. I then much prefer not having the builtin vde option or 
> even the tun/tap open code and only keep -tun-fd.  (from -tun-fd all the 
> others can be implemented by a wrapper opening the connections and 
> handing them over to QEMU)

I don't want to stop support of others virtual switch or whatever new 
interfaces! I just tell about VDE because I like it. Now ok, you can arg 
that you can make everything with a "-tun-fd" option, but this requier a 
wrapper for every use and this is I think the best way to confuse users.


> See the proposal from Fabrice some month ago on what the command line 
> parameters should look like. Very nice imho. And very easy to extend 
> with new modes (VDE, persistent TUN/TAP, whatever) without having to 
> introduce new confusing options.

Ok.

-- 
Jean-Christian de Rivaz

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

[Jean-Christian de Rivaz]

Henrik Nordstrom a écrit :

> The proposal by Fabrice looks better to me
> 
> -net usernet,macaddr=00:11:a:0:2:19 -net tunfd=10,macaddr=00:11:a:0:1:19
> 
> this way the syntax can easily be extended with new options as needed, 
> and the exact order of things is not important (you just specify the net 
> parameters as needed).
> 
> Only objection is that for the tunfd case I would use
> 
>   -net tap,fd=10,macaddr=...
> 
>> For the tap type we could have a 3rd optional parameter for the name, 
>> e.g. -net tap,macaddr,name (with name defaulting to tapX if its not 
>> specified).
> 
> 
> What about this:
> 
>    -net tap,ifname=qemu0,macaddr=...

I like it.

-- 
Jean-Christian de Rivaz

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

[Jean-Christian de Rivaz]

Henrik Nordstrom a écrit :
> On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote:
> 
>> 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).
> 
> 
> Or in line with the earlier proposal of a -net option:
> 
>   -net vde,socket=/path/to/vde.ctl,group=xxx
> 
> where socket defaults to /tmp/vde.ctl and group defaults to 0 if not 
> specified.

Nice.

>> 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 MAC of the TUN/TAP device on the host side is a completely different 
> thing and is the MAC the HOST should use on that virtual ethernet. What 
> the option to QEMU specifies is the MAC QEMU should use.

Ok. I was wrong sorry.

>> In case of this new interface, will network script still needed. If 
>> yes, how should we handle them in the new option syntax ?
> 
> 
> -net ...,script=/path/to/script

Ok, can't be more clean.

-- 
Jean-Christian de Rivaz

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

[Jim C. Brown]

On Mon, Oct 03, 2005 at 03:07:02PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jim C. Brown wrote:

> Only objection is that for the tunfd case I would use
> 
>   -net tap,fd=10,macaddr=...
> 

Since it doesn't have to be a tap device, how about this?

   -net socket,fd=10,macaddr=...

> >For the tap type we could have a 3rd optional parameter for the name, 
> >e.g. -net tap,macaddr,name (with name defaulting to tapX if its not 
> >specified).
> 
> What about this:
> 
>    -net tap,ifname=qemu0,macaddr=...
> 

That looks fine.

> Regards
> Henrik
> 



-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

On Mon, Oct 03, 2005 at 03:01:08PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
> >>In fact, if qemu supported both these things, then I don't see a reason 
> >>for
> >>-tun-fd at all (except for something like VDE).
> >
> >Agree, and a -vde option will go forward in this direction.
> 
> vde is not the only userspace switch available. Locking qemu to only vde 
> would be bad. I then much prefer not having the builtin vde option or even 
> the tun/tap open code and only keep -tun-fd.  (from -tun-fd all the others 
> can be implemented by a wrapper opening the connections and handing them 
> over to QEMU)
> 

Agreed. So "-net socket,fd=..." or at least -socket-fd (I think it should be
made clear that qemu won't require tap fds, just datagram sockets.)

> >To be clear, I don't propose to remove option at this point, but just to 
> >make qemu more easy to use for simple and most common setup.
> 
> See the proposal from Fabrice some month ago on what the command line 
> parameters should look like. Very nice imho. And very easy to extend with 
> new modes (VDE, persistent TUN/TAP, whatever) without having to introduce 
> new confusing options.
> 

Agreed.

> Regards
> Henrik
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

On Mon, Oct 03, 2005 at 02:54:42PM +0200, Henrik Nordstrom wrote:
>
> On Sun, 2 Oct 2005, Jim C. Brown wrote:
> >What it really boils down to is cleaning up the command line options for 
> >the
> >network interface(s), which up to now have been added in a hackish, 
> >piece-wise
> >manner.
> 
> And persistent TUN TAP devices makes it extremely clean on the host, and 
> as it is not difficult for qemu there is not really any reason why not.
> 
> One could obviously drop all the TUN/TAP setup code from qemu, requiring 
> the user to wrap qemu in some application passing it already opened 
> sockets using -tun-fd, but this will be a bit cumbersome to users.. but on 
> the other hand not worse than the users using VDE or similar userspace 
> switches/hubs.

This is definitely the wrong way to go. A separate program shouldn't be necessary
for handling what is probably the most common networking mode for qemu. qemu
should support using tap devices (persistent or otherwise) on its own in an
easy-to-understand manner. In fact, I like Fabrice's -net syntax.

An argument for adding vde support in qemu itself does exist - but VDE provides
its own wrapper so thats not really too much hassle for the end user. Also,
VDE may not be popular enough to justify adding vde-specific code to qemu.
(I haven't taken any polls, so I don't know if it is or not. Personally I would
have no objection. BTW, it seems bochs has native support for vde now.)

> 
> >In fact, if qemu supported both these things, then I don't see a reason for
> >-tun-fd at all (except for something like VDE).
> 
> VDE and a number of other similar applications is a fairly strong reason 
> to support the -tun-fd functionality I would say.
> 

I'd argue that -tun-fd is the wrong name. However, there may be less popular
switches (maybe someone can make qemu run on uml_switch for example) - so the
functionality should stay. Incidently, does the current -tun-fd code work
for windows hosts?

> 
> Regards
> Henrik
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Fabrice Bellard]

Hi,

Sorry for the lack of comment. I mostly use the 'user-net' networking so 
I never bothered much about TUN/TAP.

What I can say is that the '-net xxx' option will be implemented to 
solve the existing issues. My only concern is about ensuring backward 
compatibility (if no one needs it then it is much simpler).

Another point is that I am very tempted to integrate a feature to 
connect several qemu without needing an external program such as VDE. I 
am thinking of it because it would be relatively easy to add to the 
existing user-net code (user-net already simulates a kind of LAN).

Fabrice.

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

[Christian MICHON]

to do so, does that mean we would need to launch a 1st qemu
instance which would contain the dhcp server, and next qemu
instances would connect to it ?

if so, 'qemu -server' and 'qemu -client -connect_to server' could
be useful...


On 10/3/05, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> Sorry for the lack of comment. I mostly use the 'user-net' networking so
> I never bothered much about TUN/TAP.
>
> What I can say is that the '-net xxx' option will be implemented to
> solve the existing issues. My only concern is about ensuring backward
> compatibility (if no one needs it then it is much simpler).
>
> Another point is that I am very tempted to integrate a feature to
> connect several qemu without needing an external program such as VDE. I
> am thinking of it because it would be relatively easy to add to the
> existing user-net code (user-net already simulates a kind of LAN).
>
> Fabrice.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Christian

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

[Jean-Christian de Rivaz]

Christian MICHON a écrit :
> to do so, does that mean we would need to launch a 1st qemu
> instance which would contain the dhcp server, and next qemu
> instances would connect to it ?
> 
> if so, 'qemu -server' and 'qemu -client -connect_to server' could
> be useful...

As I understand and with what I know, you can do that now using a 
virtual network (VDE for example). What matter is that fact that two 
qemu instances are connected on the same network. DHCP protocol (like 
any others netowrk protocol) is over that network and is not visible to 
qemu.

To do what you wants, you have to use to different operating system 
image, one that contains a DHCP server, and the second that contain a 
DHCP client.

1) create a virtual switch: "vde_switch -s /tmp/my_switch.ctl"

2) start a virtual server: "vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda 
dhcp-server.bin [...]"

3) start a virtual client: "vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda 
dhcp-client.bin [...]"

-- 
Jean-Christian de Rivaz

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

[Jim C. Brown]

On Mon, Oct 03, 2005 at 08:29:13PM +0200, Fabrice Bellard wrote:
> Hi,
> 
> Sorry for the lack of comment. I mostly use the 'user-net' networking so 
> I never bothered much about TUN/TAP.
> 
> What I can say is that the '-net xxx' option will be implemented to 
> solve the existing issues. My only concern is about ensuring backward 
> compatibility (if no one needs it then it is much simpler).
> 

Doubtful. Not many use tundev.c or tapdev.c

VDE is more popular but fixing it for a new syntax is a trivial change.
(Probably a one liner, even.) AFAIK nothing else will care.

> Another point is that I am very tempted to integrate a feature to 
> connect several qemu without needing an external program such as VDE. I 
> am thinking of it because it would be relatively easy to add to the 
> existing user-net code (user-net already simulates a kind of LAN).
> 

How would the syntax for this work?

> Fabrice.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Christian MICHON]

no vde for windows hosts :(

On 10/3/05, Jean-Christian de Rivaz <jc@eclis.ch> wrote:
> Christian MICHON a écrit :
> > to do so, does that mean we would need to launch a 1st qemu
> > instance which would contain the dhcp server, and next qemu
> > instances would connect to it ?
> >
> > if so, 'qemu -server' and 'qemu -client -connect_to server' could
> > be useful...
>
> As I understand and with what I know, you can do that now using a
> virtual network (VDE for example). What matter is that fact that two
> qemu instances are connected on the same network. DHCP protocol (like
> any others netowrk protocol) is over that network and is not visible to
> qemu.
>
> To do what you wants, you have to use to different operating system
> image, one that contains a DHCP server, and the second that contain a
> DHCP client.
>
> 1) create a virtual switch: "vde_switch -s /tmp/my_switch.ctl"
>
> 2) start a virtual server: "vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda
> dhcp-server.bin [...]"
>
> 3) start a virtual client: "vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda
> dhcp-client.bin [...]"
>
> --
> Jean-Christian de Rivaz
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Christian

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

[Jean-Christian de Rivaz]

Christian MICHON a écrit :
> no vde for windows hosts :(

Have you tryed ? Because the VDE code don't interract to mutch with the 
system (only require POSIX OS) and contains a lot of "win32" test as you 
can see in the attachement. But there is no document how to compile 
that. Since there are "win32" test into the configure, I think this will 
require Cygwin tools.

-- 
Jean-Christian de Rivaz

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

[Matteo]

Le lundi 03 octobre 2005 à 20:29 +0200, Fabrice Bellard a écrit :
> Another point is that I am very tempted to integrate a feature to 
> connect several qemu without needing an external program such as VDE. I 
> am thinking of it because it would be relatively easy to add to the 
> existing user-net code (user-net already simulates a kind of LAN).
> 

That would be a very good idea. I've always thought of installing vde or
any other application to make a network of VMs painfull. Moreover you
then need to configure each host, write scripts... The integration to
the existing user net would be great for most of the cases. Non trivial
ones will maybe need the fine tuning tun/tap devices allow, but I think
most users want simplicity

Mattéo

> Fabrice.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

[Jim C. Brown]

On Tue, Oct 04, 2005 at 10:23:26AM +0200, Matteo wrote:
> That would be a very good idea. I've always thought of installing vde or
> any other application to make a network of VMs painfull.

Well, i find that a qemu_switch would be more convient as you could set up
the network at boot time (like i do with vde now).

> Moreover you
> then need to configure each host, write scripts... 

There is only one host. And if u don't use tuntap, then no host configuration
is required (remember slirpvde?).

Guests have to be configured anyways (tho slirpvde includes a dhcp server).

> The integration to
> the existing user net would be great for most of the cases. Non trivial
> ones will maybe need the fine tuning tun/tap devices allow, but I think
> most users want simplicity

VDE provides this already. Of course, a user-net based solution for qemu guest
networks could do a few things that slirpvde can't (like -redir support). It is
definitely worth trying for.

For the most part tho, it's just duplicating functionality that we already have.

> 
> Matt?o
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.