Hello,
networking does not come up on my machine. I changed the script
/etc/kvm/kvm-ifup to include two logging statements:
--------------------------------------- cut
#! /bin/sh
# Script to bring a network (tap) device for qemu-kvm up
# The idea is to add the tap device to the same bridge
# as we have default routing to.
switch=$(ip route ls | \
awk '/^default / {
for(i=0;i<NF;i++) { if ($i == "dev") { print $(i+1); exit; } }
}'
)
/sbin/ifconfig $1 0.0.0.0 up
logger -p daemon.info "kvm: found switch $switch"
# only add the interface to default-route bridge if we
# have such interface (with default route) and if that
# interface is actually a bridge.
if [ -n "$switch" -a -d /sys/class/net/$switch/bridge/. ]; then
/usr/sbin/brctl addif $switch $1 || :
logger -p daemon.info "kvm: added interface $1 to $switch"
fi
--------------------------------------- cut
My "normal" routing table looks like this:
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
217.0.118.194 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
After starting a VM, I found this in my /var/log/daemon.log:
Mar 6 16:12:22 debian logger: kvm: found switch ppp0
This is obviously wrong. I suggest to check for bridge interfaces
instead of interfaces with a default route, and add the tapN interface
to that.
Kind regards,
--Toni++
Toni Mueller wrote: [] The thing here is that the supplied script is very simplistic. It is only intended for trivial most common situation, and even that is not completely handled (the bridge isn't created automatically). This is because kvm isn't really intended to be smart and figure it all out, and because messing with the network is just too fragile (I for one will hate packages which substitute my eth0 with a bridge and change firewall rules behind my back). There are two ways around this, and neither of them involves changes in kvm package. One is to use more advanced support tools like virt-manager, which has quite large piece of code to support networking in different variations. And another is to change the script in question (/etc/kvm/kvm-ifup) to do what is right on your host. I'd say this is the best option - you know your setup, and it is a configuration file for exactly this reason. Default /etc/kvm/kvm-ifup will never try to cover all cases. Maybe it is a good idea to look at the bridge and add the interface to the bridge if there's only one bridge. But I don't really see why it is better than just using the interface with default route -- maybe even that is overkill and/or illogical: since we don't create the bridge at install time, why should we try to find such a bridge in kvm-ifup? Toni, do you agree? Thanks! /mjt
Hi, agreed. This would easily become very fragile. This is what I did even before reporting the bug. Ok. I missed the "config file" part when I reported the bug. Ummm... I'd say that the current situation where the default networking is to set up the virtual machine like a PC behind a DSL router with NAT, is too simplistic in almost all cases. But you have a point in that there are many ways to configure something else, and that it would be too complex and error prone to reconfigure the system automatically. Kind regards, --Toni++
Networking starts only on the first time that I start an XP virtual machine after a reboot of the actual machine. If I subsequently restart the virtual machine, or the XP instance within it, the network only comes up enough for me to connect to my Samba server. I can't get out to the Internet or ping some machines on my network.
Gary Dale wrote: Gary, can you please describe why do you think your problem is the same as #572784? As far as I'm concerned, #572784 is, like, "fixed not a bug". For the issue you describes, I guess it is entirely different thing and is either configuration error on your part or some "integration" package (like vde or virt-manager) doing something wrong. But since you provided no details, and since I know it works for many people including me, it is very difficult to even guess correctly what might be wrong here. /mjt
Michael Tokarev wrote:
My problem looked similar based on the subject line.
My qemu-kvm command line is
kvm -cpu phenom -enable-kvm -vga std -localtime -hda
~/.virt/windowsxp/windows.qcow -m 1G
My virtual machine is running Windows XP/Pro with SP3 and all the later
patches. I have very little else on it other than Pinnacle Studio 9.
My main board is a Gigabyte GA-MA790GP-UD4H with a Realtek 8111C NIC
onboard. I'm connecting to a Linksys WRT610N router which provides dhcp
services while my Samba server is running Debian/Lenny.
My /etc/network/interfaces file is:
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0
mapping eth1
script grep
map eth1
iface eth0 inet manual
auto br0
iface br0 inet dhcp
pre-up /usr/sbin/tunctl -u garydale -t tap0
pre-up ifconfig tap0 up
bridge_ports all tap0
post-down ifconfig tap0 down
post-down tunctl -d tap0
severity 572784 wishlist thanks Toni Mueller wrote: Aha. I did not immediately realize #569990 is from you too :) All files in /etc in Debian are config files. I think I'll set severity to wishlist for this. But I'm not sure it will be addressed in any reasonable future. Thanks! /mjt
Gary Dale wrote: [] Aha. So it is user-mode networking. Gary, that's.. difficult. The thing is, there is no way I can think of the situation you describe. With user-mode networking, kvm is just a normal user-space process, like your web browser etc. You restart it, and it acts the same way as before -- unless something else started on your host which prevents it from working correctly. This is all not really relevant. Note that with user-mode net in kvm, the dhcp server used is built-in to kvm, not any your local one. It provides fixed ip address - 10.2.2.2 if memory serves me right. See http://www.linux-kvm.org/page/Networking for additional networking options. Note that you almost completed bridged networking setup for kvm for non-root user, only the kvm command line is missing. Please check your networking setup, and if you still has the issue please file a new bug. Thanks. /mjt
Michael Tokarev wrote: Which unfortunately it doesn't. To make matters worse, it sometimes doesn't start even after a reboot of my physical machine - which is also what the original bug report contained. However so far as I have observed, it never survives a reboot of my virtual OS. Yes, the address 10.0.2.15 is given by KVM on my setup, with 10.0.2.2 as the default gateway. I've read the kvm networking page but it is not a model of clarity. I can't even always tell where one subsection ends and another begins. The different use cases simply confuse things. From my reading there are simply two options - to use the user networking or to use a bridge. There are then some options for setting up and configuring a bridge. Since it sometimes works, I'm not sure what is missing. The kvm networking page doesn't mention any special options for the kvm command line using a public bridge with option 1. I've tried adding the options -net tap alone and in combination with -net nic,macaddr= using the tap0 mac address and also a made-up mac address. Neither worked. -net tap by itself even prevents the virtual machine from starting.
OK, I think I've got it now. I found http://blog.cynapses.org/2007/07/12/qemu-kvm-internal-network-setup/ which provided some additional settings for the -net options. Using a made-up mac address and -net tap,ifname=tap0,script=no gave me an IP address from my local network and allowed Windows Update to locate 8 updates. However, I still couldn't browse the Internet, which was confusing. Moreover, network operations seemed slow. Including model=rtl8139 seems to be important. Once I did that, I could get out onto the Internet. The kvm networking page doesn't mention these essential command line settings. Perhaps you could ask the page maintainer to include them? I'd do it myself but I'm still having a network issue - br0 doesn't come up when I boot - I have to start in single-user mode, run dhclient br0, then resume the boot. I don't feel comfortable offering people network advice when I'm having a basic problem like that. :) Thanks for your help!
Gary Dale wrote: If windows is able to locate updates it means everything on the IP (internet protocol) side works as expected. Note that rtl8139 is the default model of the virtual NIC, so this parameter -- "model=rtl8139" -- does nothing for you. them are essential. For all others default setup (without -net parameters at all, which gives you user-mode networking) works just fine (but it is slow). I repeat: what you describe is impossible to get "using" a bug in kvm. Saying that kvm guest can't connect to internet is like saying that firefox is unable to display pages - it is solely your local setup, firefox works for millions of people worldwide. And the whole thing is really a support/help request, which is not a good thing for BTS. From what I see, your network setup (/etc/network/interfaces you provided before) is correct, at least I don't see any obvious issues. Maybe it's your bad karma? :) /mjt
Hi, I can't say whether this problem is related, but after the most recent upgrades as per your directions, I got this in my logs: debian kernel: [67410.957676] tun: Universal TUN/TAP device driver, 1.6 debian kernel: [67410.957680] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> debian kernel: [67410.971285] device tap0 entered promiscuous mode debian kernel: [67410.971294] br0: port 2(tap0) entering learning state debian kernel: [67416.697973] kvm: 23290: cpu0 unhandled rdmsr: 0x417 debian kernel: [67420.459195] br0: topology change detected, propagating debian kernel: [67420.459200] br0: port 2(tap0) entering forwarding state debian kernel: [67422.065974] tap0: no IPv6 routers present debian kernel: [67463.483374] br0: port 2(tap0) entering disabled state debian kernel: [67463.494830] device tap0 left promiscuous mode debian kernel: [67463.494835] br0: port 2(tap0) entering disabled state debian kernel: [67465.652634] device tap0 entered promiscuous mode debian kernel: [67465.652643] br0: port 2(tap0) entering learning state debian kernel: [67470.219679] kvm: 23366: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop debian kernel: [67470.223683] kvm: emulating exchange as write debian kernel: [67475.404783] br0: topology change detected, propagating debian kernel: [67475.404788] br0: port 2(tap0) entering forwarding state debian kernel: [67476.686667] tap0: no IPv6 routers present debian kernel: [67867.633293] device br0 entered promiscuous mode debian kernel: [67869.617175] device br0 left promiscuous mode debian kernel: [67874.187981] device br0 entered promiscuous mode debian kernel: [67879.033415] device br0 left promiscuous mode debian kernel: [67886.797121] device br0 entered promiscuous mode debian kernel: [67916.480988] device br0 left promiscuous mode debian kernel: [67928.746786] device br0 entered promiscuous mode debian kernel: [67957.554007] device br0 left promiscuous mode debian kernel: [68019.030733] device tap0 left promiscuous mode debian kernel: [68019.030740] br0: port 2(tap0) entering disabled state debian kernel: [68024.255871] device tap0 entered promiscuous mode debian kernel: [68024.255871] br0: port 2(tap0) entering learning state debian kernel: [68032.007266] device br0 entered promiscuous mode debian kernel: [68034.601860] br0: topology change detected, propagating debian kernel: [68034.601865] br0: port 2(tap0) entering forwarding state debian kernel: [68048.244230] device br0 left promiscuous mode debian kernel: [68106.220029] kvm: 23366: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop debian kernel: [68969.104298] br0: port 2(tap0) entering disabled state debian kernel: [68969.114532] device tap0 left promiscuous mode debian kernel: [68969.114538] br0: port 2(tap0) entering disabled state debian kernel: Kernel logging (proc) stopped. The "entered/left promiscuous mode" statements result from my trying to use tcpdump. Kind regards, --Toni++
Hi Michael, I just see that the following bugs seem to be relevant: #518643, #568293 (mine) $ p kvm kvm: Installed: 1:0.12.3+dfsg-5tls $ p qemu-kvm qemu-kvm: Installed: 0.12.3+dfsg-5tls Kind regards, --Toni++
tags 572784 + wontfix thanks Replying to an old bugreport... [] I'm marking this bugreport as "wontfix", because we now have better opportunity for this: management tools like libvirt. These performs network configuration for lots of basic cases. If you don't want to use libvirt or similar, you're free to configure your system networking manually, and qemu-kvm package should not stay on the way. It provides just a hint of how network setup script may look like. Thanks, /mjt