Re: QEMU /dev/tun issue with tun device number > 3 (more than 4 guests)
On Thu, Oct 25, 2007 at 11:03:56AM -0200, Marcus Andree wrote: > comments inline. > > On 10/25/07, Michael <[EMAIL PROTECTED]> wrote: > > Hi, > > > > thanks for your fast answer. > > > > Marcus Andree schrieb: > > > Maybe you'll have to compile a new kernel. There's an options(4) option > > > called tun. I had to add something like > > > > > > pseudo-device tun 16 > > > > I read something while googling for this issue that you had to add > > something like that for older versions of OpenBSD like before 3.6 or > > even 3.4. > > > > Yep. It was some time ago ;) > > > > on a kernel config file once. If I remember correctly, the default is the > > > kernel > > > to allocate 4 tun channels. That would explain why it's failing in the > > > 5th QEMU > > > guest. > > > > > > Don't forget that customized kernels aren't "supported". > > > > Well, more than 4 tun interfaces ARE working ... if I create /dev/tun4 > > or higher manually with (cd /dev; ./MAKEDEV tun4) and also manually add > > tun4 to the bridge (brconfig bridge0 add tun4 up) ... but QEMU does that > > for tun0 - tun3 on its own ... its just not working for more than the > > first four interfaces. > > > By stating that the interfaces ARE working, you mean that they not only > exist but the bridges are correctly configured and functional, right? > It is possible to use more then 4 tun(4) interfaces. No porblems. > If more than 4 tun devices work properly on the openbsd-side, then this > thing should be a qemu issue, be it fixable from an external shell > script or not. > Looks like an issue with the if-up shell script or qemu. > > Btw, would something like > > > > ![ -c /dev/tun4 ] || (cd /dev; ./MAKEDEV tun4) > > > > work inside a /etc/hostname.tun4 file, just to make sure the device exists? > > > > I'd prefer to work directly with mknod than cd'ing to /dev and firing up > MAKEDEV > to create just one character device. > Bad idea. The major number of tun is paltform dependent. Calling MAKEDEV is by far better. -- :wq Claudio
Re: QEMU /dev/tun issue with tun device number > 3 (more than 4 guests)
On Thu, Oct 25, 2007 at 10:37:32AM -0200, Marcus Andree wrote: > On 10/25/07, Michael <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've tried to run 5 QEMU guests simultanously but when trying to start > > the 5th I'll get the following error message: > > > > warning: could not open /dev/tun7 (No such file or directory): no > > virtual network emulation > > Could not initialize device 'tap' > > > > I have no idea why it looks for /dev/tun7 but after that I cd'ed to /dev > > and issued the command "./MAKEDEV tun4" but now I get the following > > message when starting qemu: > > > > > > Maybe you'll have to compile a new kernel. There's an options(4) option > called tun. I had to add something like > > pseudo-device tun 16 > > on a kernel config file once. If I remember correctly, the default is the > kernel > to allocate 4 tun channels. That would explain why it's failing in the 5th > QEMU > guest. > > Don't forget that customized kernels aren't "supported". > This is no longer true. tun(4) can be auto generated without issues. The only thing you need to make sure is that the /dev nodes exist. I'm running multiple qemu sessions with up to 20 tun interfaces without issues but I'm not using if-up at all. I'm passing fds to qemu with -net tap,vlan=$id,fd=$fd -- :wq Claudio
Re: QEMU /dev/tun issue with tun device number > 3 (more than 4 guests)
comments inline. On 10/25/07, Michael <[EMAIL PROTECTED]> wrote: > Hi, > > thanks for your fast answer. > > Marcus Andree schrieb: > > Maybe you'll have to compile a new kernel. There's an options(4) option > > called tun. I had to add something like > > > > pseudo-device tun 16 > > I read something while googling for this issue that you had to add > something like that for older versions of OpenBSD like before 3.6 or > even 3.4. > Yep. It was some time ago ;) > > on a kernel config file once. If I remember correctly, the default is the > > kernel > > to allocate 4 tun channels. That would explain why it's failing in the 5th > > QEMU > > guest. > > > > Don't forget that customized kernels aren't "supported". > > Well, more than 4 tun interfaces ARE working ... if I create /dev/tun4 > or higher manually with (cd /dev; ./MAKEDEV tun4) and also manually add > tun4 to the bridge (brconfig bridge0 add tun4 up) ... but QEMU does that > for tun0 - tun3 on its own ... its just not working for more than the > first four interfaces. > By stating that the interfaces ARE working, you mean that they not only exist but the bridges are correctly configured and functional, right? If more than 4 tun devices work properly on the openbsd-side, then this thing should be a qemu issue, be it fixable from an external shell script or not. > Btw, would something like > > ![ -c /dev/tun4 ] || (cd /dev; ./MAKEDEV tun4) > > work inside a /etc/hostname.tun4 file, just to make sure the device exists? > I'd prefer to work directly with mknod than cd'ing to /dev and firing up MAKEDEV to create just one character device. > > Michael
Re: QEMU /dev/tun issue with tun device number > 3 (more than 4 guests)
On 10/25/07, Michael <[EMAIL PROTECTED]> wrote: > Hi, > > I've tried to run 5 QEMU guests simultanously but when trying to start > the 5th I'll get the following error message: > > warning: could not open /dev/tun7 (No such file or directory): no > virtual network emulation > Could not initialize device 'tap' > > I have no idea why it looks for /dev/tun7 but after that I cd'ed to /dev > and issued the command "./MAKEDEV tun4" but now I get the following > message when starting qemu: > Maybe you'll have to compile a new kernel. There's an options(4) option called tun. I had to add something like pseudo-device tun 16 on a kernel config file once. If I remember correctly, the default is the kernel to allocate 4 tun channels. That would explain why it's failing in the 5th QEMU guest. Don't forget that customized kernels aren't "supported".
Re: QEMU /dev/tun issue with tun device number > 3 (more than 4 guests)
Hi, thanks for your fast answer. Marcus Andree schrieb: > Maybe you'll have to compile a new kernel. There's an options(4) option > called tun. I had to add something like > > pseudo-device tun 16 I read something while googling for this issue that you had to add something like that for older versions of OpenBSD like before 3.6 or even 3.4. > on a kernel config file once. If I remember correctly, the default is the > kernel > to allocate 4 tun channels. That would explain why it's failing in the 5th > QEMU > guest. > > Don't forget that customized kernels aren't "supported". Well, more than 4 tun interfaces ARE working ... if I create /dev/tun4 or higher manually with (cd /dev; ./MAKEDEV tun4) and also manually add tun4 to the bridge (brconfig bridge0 add tun4 up) ... but QEMU does that for tun0 - tun3 on its own ... its just not working for more than the first four interfaces. Btw, would something like ![ -c /dev/tun4 ] || (cd /dev; ./MAKEDEV tun4) work inside a /etc/hostname.tun4 file, just to make sure the device exists? Michael
