Red Hat Bugzilla – Bug 620579
Virtio network takes 90 seconds to appear in Win XP KVM
Last modified: 2013-01-09 06:38:18 EST
Description of problem:
My windows XP KVM virtual machine acts as if the network interface doesn't
exist for about 90 seconds after booting.
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):
Steps to Reproduce:
1. Start KVM
2. Try to talk to network, nothing happens for about 90 seconds.
90 second delay for networking
No more than a few seconds.
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:
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
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
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.