Bug 620579
| Summary: | Virtio network takes 90 seconds to appear in Win XP KVM | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Horsley <horsley1953> | ||||
| Component: | qemu | Assignee: | Justin M. Forbes <jforbes> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | amit.shah, berrange, bugzilla-redhat, dwmw2, ehabkost, gcosta, itamar, jaswinder, jforbes, knoel, markmc, ondrejj, scottt.tw, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-08-27 00:11:29 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Tom Horsley
2010-08-02 21:52:40 UTC
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. |