Bug 620579 - Virtio network takes 90 seconds to appear in Win XP KVM
Summary: Virtio network takes 90 seconds to appear in Win XP KVM
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-02 21:52 UTC by Tom Horsley
Modified: 2013-01-09 11:38 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-27 00:11:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The xml machine definition for the Windows XP KVM (1.71 KB, application/xml)
2010-08-02 21:54 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2010-08-02 21:52:40 UTC
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.

Comment 1 Tom Horsley 2010-08-02 21:54:58 UTC
Created attachment 436141 [details]
The xml machine definition for the Windows XP KVM

Comment 2 Tom Horsley 2010-08-03 23:11:27 UTC
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.

Comment 3 Tom Horsley 2010-08-06 01:35:19 UTC
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).

Comment 4 Tom Horsley 2010-08-27 00:11:29 UTC
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 :-).

Comment 5 Brian 2011-01-11 19:04:39 UTC
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.

Comment 6 Tom Horsley 2011-01-11 20:27:43 UTC
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.

Comment 7 Brian 2011-01-11 21:31:27 UTC
I only get it with VertIO.  Switching back to hardware emulation, it boots as expected.


Note You need to log in before you can comment on or make changes to this bug.