QEMU /dev/tun issue with tun device number 3 (more than 4 guests)
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: Initializing ??.. ifconfig: SIOCGIFFLAGS: Device not configured ifconfig: SIOCGIFFLAGS: Device not configured ifconfig: SIOCIFCREATE: File exists brconfig: bridge0: ??: No such file or directory Its the same message even if I create a tun7 device instead. QEMU starts but is not reachable. I figured out that when adding the new tun4 device to the bridge manually shortly after qemu was started, or if activated with link0 manually, the guest becomes available so I figure that there is some issue with qemu sending the right device name to /etc/qemu-ifup as it only shows ?? instead of tunX like it normally does. Specifying name=/dev/tun4 as -net tap parameter doesn't work either. Someone got an idea or time to debug this? Is this an OpenBSD or QEMU issue? Thanks in advance, Michael PS: i386 machine with OpenBSD 4.1-stable. Problem persists even after backporting QEMU version 0.9 from OpenBSD 4.2 to 4.1.
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
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: snip 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)
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 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: snip 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)
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
