Bug#607290: qemu-kvm scripts not run
Package: qemu-kvm Version: 0.12.5+dfsg-5 Severity: important Hey, I'm experiencing a weird problem with kvm. It seems that network scripts aren't run at all, and an internal script is always used, which won't work as user: yape...@oban: kvm -net nic -net tap could not configure /dev/net/tun: Operation not permitted which is expected, I don't have the capabilities to do the required ioctl on the tun device. running it as root or through sudo works fine. By default, manpage says it should use /etc/kvm/kvm-ifup script, which doesn't do anything tun related, which means it's done inside kvm itself. Using script=no fixes the problem but means one has to setup everything himself. Regards, -- Yves-Alexis -- Package-specific info: /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority bogomips: 4388.57 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority bogomips: 4388.96 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-grsec-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-kvm depends on: ii adduser 3.112+nmu2 add and remove users and groups ii bridge-utils1.4-5Utilities for configuring the Linu ii iproute 20100519-3 networking and traffic control too ii libaio1 0.3.107-7Linux kernel AIO access library - ii libasound2 1.0.23-2.1 shared library for ALSA applicatio ii libbluetooth3 4.70-1 Library to use the BlueZ Linux Blu ii libbrlapi0.54.2-6braille display access via BRLTTY ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.2-4 Multi-protocol file transfer libra ii libgnutls26 2.10.2-1 the GNU TLS library - runtime libr ii libncurses5 5.7+20100313-4 shared libraries for terminal hand ii libpci3 1:3.1.7-6Linux PCI Utilities (shared librar ii libpulse0 0.9.21-3+b1 PulseAudio client libraries ii libsasl2-2 2.1.23.dfsg1-6 Cyrus SASL - authentication abstra ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer ii libuuid12.17.2-3.3 Universally Unique ID library ii libvdeplug2 2.2.3-3 Virtual Distributed Ethernet - Plu ii libx11-62:1.3.3-4X11 client-side library ii python 2.6.6-3+squeeze3 interactive high-level object-orie ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages qemu-kvm recommends: ii linux-image-2.6.32-5-amd64 [l 2.6.32-29 Linux 2.6.32 for 64-bit PCs ii linux-image-2.6.32-5-grsec-am 2.6.32-30 Linux 2.6.32 for 64-bit PCs, Grsec Versions of packages qemu-kvm suggests: ii debootstrap 1.0.26 Bootstrap a basic Debian system pn samba none (no description available) pn vde2 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to
Bug#607290: qemu-kvm scripts not run
On jeu., 2010-12-16 at 21:08 +0300, Michael Tokarev wrote: 16.12.2010 20:40, Yves-Alexis Perez wrote: Package: qemu-kvm Version: 0.12.5+dfsg-5 Severity: important Hey, I'm experiencing a weird problem with kvm. It seems that network scripts aren't run at all, and an internal script is always used, which won't work as user: yape...@oban: kvm -net nic -net tap could not configure /dev/net/tun: Operation not permitted There's no such thing as internal script. By default qemu - given -net tap as above - _creates_ a network device, and runs the script specified only _after_ the device is created. Here, you don't have permission to _create_ a network device to start with. The various howtos found on the net seem to indicate the script is responsible for creating the device. See http://en.wikibooks.org/wiki/QEMU/Networking for example. running it as root or through sudo works fine. By default, manpage says it should use /etc/kvm/kvm-ifup script, which doesn't do anything tun related, which means it's done inside kvm itself. The script runs against already created tap device - created either by qemu itself, or pre-created (and given with ifname=NNN to qemu). Ok so passing ifname=NNN should prevent the device to be created by kvm. There's no point or ability to _create_ a tap device _inside_ the script - because it has the same permissions anyway, and because now there's no way to pass the tap device back to qemu. I thought the name was given has an argument to the script, so qemu already knows it. And that means it's possible to gain root in the script using sudo. Using script=no fixes the problem but means one has to setup everything himself. Fixes which problem? Qemu still need the tap device - either created internally or pre-created. I meant that when passing script=no, qemu didn't try to create the tap device itself, but that's wrong, it's when I used ifname=foo. Qemu does nothing with the tap device it created (or took from ifname=XXX) except of connecting it to guest. Everything else is done outside - either in the script or by external means. And the steps necessary to use this device on the host side does not depend on who created the tap device. If you want to run in as non-root you may pre-create a tap device before running qemu, and give certain user or group access to it. You may pre-configure it too, by adding to an appropriate bridge or setting up routing. Closing this bug right away, which was due to either invalid usage or some misunderstanding of how things work. Yeah, sorry. I still think there's a valid bug against the documentation, which is a bit scarse on the tap stuff. Sorry for bothering. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#607290: qemu-kvm scripts not run
16.12.2010 22:40, Yves-Alexis Perez wrote: [] There's no such thing as internal script. By default qemu - given -net tap as above - _creates_ a network device, and runs the script specified only _after_ the device is created. Here, you don't have permission to _create_ a network device to start with. The various howtos found on the net seem to indicate the script is responsible for creating the device. See http://en.wikibooks.org/wiki/QEMU/Networking for example. We can't be responsible for every error in every internet publication out there. The above wiki page is wrong in that it's wrong to _create_ the tap device inside the configuration script. [] The script runs against already created tap device - created either by qemu itself, or pre-created (and given with ifname=NNN to qemu). Ok so passing ifname=NNN should prevent the device to be created by kvm. No. qemu will create a device if it's not already exist, be it a named or randomly-numbered one. There's no point or ability to _create_ a tap device _inside_ the script - because it has the same permissions anyway, and because now there's no way to pass the tap device back to qemu. I thought the name was given has an argument to the script, so qemu already knows it. And that means it's possible to gain root in the script using sudo. Yes, the iface name is passed as first argument to the script, because qemu has it created and open at the time when the script is run. Using script=no fixes the problem but means one has to setup everything himself. Fixes which problem? Qemu still need the tap device - either created internally or pre-created. I meant that when passing script=no, qemu didn't try to create the tap device itself, but that's wrong, it's when I used ifname=foo. And you're wrong again. Qemu needs a working tap device, - either pre-created or created by qemu itself, no matter if you use ifname=foo or script=foo or script=no. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
