Description of problem: My windows XP KVM virtual machine acts as if the network interface doesn't exist for about 90 seconds after booting. See: http://lists.fedoraproject.org/pipermail/virt/2010-August/002198.html for the thread where this started. It doesn't appear to be related to the windows virtio driver version, since in my most recent experiment, I uninstalled the network interface in the device manager, rebooted the machine, and the "Add new hardware" wizard took 90 seconds to appear. This is a KVM image I've been using for several releases of fedora and which just started exhibiting this behaviour with the latest round of qemu and libvirt updates. There are no noticeable network speed problems once it does appear. It seems to work fine after it shows up. The KVM was installed way back when with an XP sp1 CD, but has had online updates installed over time and is at sp3 now with all updates as of Aug 1st. Version-Release number of selected component (if applicable): libvirt-0.8.2-1.fc13.x86_64 qemu-common-0.12.3-8.fc13.x86_64 gpxe-roms-qemu-1.0.0-1.fc13.noarch qemu-system-x86-0.12.3-8.fc13.x86_64 qemu-kvm-0.12.3-8.fc13.x86_64 qemu-img-0.12.3-8.fc13.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Start KVM 2. Try to talk to network, nothing happens for about 90 seconds. 3. Actual results: 90 second delay for networking Expected results: No more than a few seconds. Additional info: Here's the qemu log entry for booting the KVM: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name hog4 -uuid 5909c4ae-6038-e841-18cf-072171444384 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/hog4.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -drive file=/zooty/images/hog4.img,if=none,id=drive-virtio-disk0,boot=on -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device virtio-net-pci,vlan=0,id=net0,mac=54:52:00:78:6e:1f,bus=pci.0,addr=0x5 -net tap,fd=47,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 char device redirected to /dev/pts/1 I'll attach the xml dump of the machine definition.
Created attachment 436141 [details] The xml machine definition for the Windows XP KVM
This may have more to do with Windows XP than qemu. I just tried running the same KVM image after booting an old fedora 11 partition (with old libvirt and qemu), and I see the same network delay. I now suspect it is more likely that some XP update introduced this delay.
OK, I created a new Windows XP KVM from scratch and started sneaking up on the network creation delay. There was no delay with a fresh install, but I eventually got to the optional windows update for: .NET Framework 4 client profile And whatever the hell that is makes the network take 90 seconds to start at boot time. If I uninstall that update, the network is up as soon as I finish booting. I've asked over on the microsoft forums what the heck is going on: http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/thread/cb75c4dc-e0af-4b22-85b2-c2c1b08bfea1 But this sure seems like it probably has nothing to do with qemu (but I'd have to see if a real machine has the same problem after that update, to be absolutely positive). P.S. The new machine creation ran into bug 579348, but as long as I keep booting from the CD it works (I have no idea why my old images I've ported since f11 work though).
I finally tried this on a real machine and got the same hang, so I am now positive this is not a bug in qemu - it belongs to Microsoft :-).
I have this issue on a 2003 server guest and the .Net Framework 4 client profile is NOT installed. Additionally, I don't think it's accurate to simply say this is a Microsoft bug, since it doesn't seem to be exclusive to the .Net Framework 4 client profile -- since I didn't have it installed but I experienced the same delay issue, but I do not have this update installed. If it were strictly a Microsoft bug, wouldn't we see it with other drivers too? Are we so certain that the VirtIO drivers are written perfectly? And since we can't modify Microsoft's closed source software, wouldn't "perfect" mean something that just works. Ya, it's a crappy situation, but this is why we avoid MS in the first place. I'm actually installing the .NET Framework 4 Client Profile Setup now and see uninstalling it helps. Maybe that "ngen update" script will help.
Like I said in comment 4, when I tried it on real hardware I got the same delay from the .Net update, so the particular problem I had certainly had nothing to do with being a virtual machine.
I only get it with VertIO. Switching back to hardware emulation, it boots as expected.