[Users] Virtio NIC in Windows failing at boot
--_000_97c686f412944d9f80995124b7d7f9b7BN1PR04MB170namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Ever since moving from oVirt 3.1 (with Fedora image-based nodes) to oVirt 3= .3 (and now 3.3.1) with CentOS 6.4 (now 6.5) nodes, I've been having a seri= ous problem with our Windows guests. To my knowledge, none of the Linux gu= ests have ever been affected. The problem appears when a Windows guest is rebooted. Occasionally this ha= ppens during maintenance work but more often as a result of Microsoft updat= es which require a reboot. The most recent batch of these that we allowed = resulted in something like 35 of 40 Windows guests losing networking. What we see is that the VirtIO Ethernet Adapter is enabled but shows no evi= dence of actually being connected to the network. The MAC never appears in= our switches, etc. The solution is to connect to the guest via console an= d manually disable, then enable, the NIC. Problem solved. I've found at least two other references to this issue: http://forum.proxmox.com/threads/11160-Windows-2008-R2-Server-Standard-Edit= ion-VIRTIO-NIC-Drivers-dont-work-on-boot (exactly our issue) http://forum.proxmox.com/threads/16550-Windows-server-2012-blue-screen-virt= io-win-ethernet-card (similar, though we never see a crash) Needless to say, this is super annoying. Right now it seems my options see= m to be: 1. Implement a script to reset the NIC as suggested in the first link. 2. Revert to e1000 but not sure how much that will hurt performance and/or= whether it will limit us to 1 Gbps throughput. Has anyone experienced this? Would I likely have better luck on the VirtIO= list? We've been running VirtIO Ethernet 61.63.103.3000 from virtio-win-0= .1-65.iso but I just now found 61.65.104.7400 included in virtio-win-0.1-74= .iso. Perhaps that will help although I don't see anything relevant in the= changelog. Thanks, Allen Belletti AVP Ed. Tech Engineering Innovation Georgia Gwinnett College 678-407-5093 www.ggc.edu --_000_97c686f412944d9f80995124b7d7f9b7BN1PR04MB170namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<style type=3D"text/css" id=3D"owaParaStyle" style=3D"">=0A= <!--=0A= p=0A= {margin-top:0;=0A= margin-bottom:0}=0A= -->=0A= P {margin-top:0;margin-bottom:0;}</style> </head> <body dir=3D"ltr" tabindex=3D"0" fpstyle=3D"1" aria-label=3D"Message body"> <div name=3D"divtagdefaultwrapper" id=3D"divtagdefaultwrapper" style=3D"fon= t-family: Calibri,Arial,Helvetica,sans-serif; font-size: 12pt; color: #0000= 00; margin: 0"> <p>Hi All, </p> <p><br> </p> <p>Ever since moving from oVirt 3.1 (with Fedora image-based nodes) to oVir= t 3.3 (and now 3.3.1) with CentOS 6.4 (now 6.5) nodes, I've been having a s= erious problem with our Windows guests. To my knowledge, none of the = Linux guests have ever been affected.</p> <p><br> </p> <p>The problem appears when a Windows guest is rebooted. Occasionally= this happens during maintenance work but more often as a result of Microso= ft updates which require a reboot. The most recent batch of these tha= t we allowed resulted in something like 35 of 40 Windows guests losing networking.</p> <p><br> </p> <p>What we see is that the VirtIO Ethernet Adapter is enabled but shows no = evidence of actually being connected to the network. The MAC never ap= pears in our switches, etc. The solution is to connect to the guest v= ia console and manually disable, then enable, the NIC. Problem solved.</p> <p><br> </p> <p>I've found at least two other references to this issue:</p> <p><a href=3D"http://forum.proxmox.com/threads/11160-Windows-2008-R2-Server= -Standard-Edition-VIRTIO-NIC-Drivers-dont-work-on-boot" target=3D"_blank" t= itle=3D"http://forum.proxmox.com/threads/11160-Windows-2008-R2-Server-Stand= ard-Edition-VIRTIO-NIC-Drivers-dont-work-on-boot Ctrl+click or tap to follow link">http://forum.proxmox.com/threads/1116= 0-Windows-2008-R2-Server-Standard-Edition-VIRTIO-NIC-Drivers-dont-work-on-b= oot</a> (exactly our issue)</p> <p><a href=3D"http://forum.proxmox.com/threads/16550-Windows-server-2012-bl= ue-screen-virtio-win-ethernet-card" target=3D"_blank" title=3D"http://forum= .proxmox.com/threads/16550-Windows-server-2012-blue-screen-virtio-win-ether= net-card Ctrl+click or tap to follow link">http://forum.proxmox.com/threads/1655= 0-Windows-server-2012-blue-screen-virtio-win-ethernet-card</a> (simila= r, though we never see a crash)</p> <p><br> </p> <p>Needless to say, this is super annoying. Right now it seems my opt= ions seem to be:</p> <p>1. Implement a script to reset the NIC as suggested in the first l= ink.</p> <p>2. Revert to e1000 but not sure how much that will hurt performanc= e and/or whether it will limit us to 1 Gbps throughput.</p> <p><br> </p> <p><span style=3D"font-size: 12pt;">Has anyone experienced this? Woul= d I likely have better luck on the VirtIO list? We've been running Vi= rtIO Ethernet 61.63.103.3000 from virtio-win-0.1-65.iso but I just now foun= d 61.65.104.7400 included in virtio-win-0.1-74.iso. Perhaps that will help although I don't see anything relevant in the= changelog.</span></p> <p><br> </p> <p>Thanks,</p> <p><br> </p> <div> <div style=3D"font-family:Tahoma; font-size:13px"><span lang=3D"en-US"> <div style=3D"margin:0pt"><font face=3D"Calibri,sans-serif" size=3D"2"><spa= n style=3D"font-size:11pt">Allen Belletti<br> </span></font></div> <div style=3D"margin:0pt"><font face=3D"Calibri,sans-serif" size=3D"2"><spa= n style=3D"font-size:11pt">AVP Ed. Tech Engineering Innovation<br> </span></font></div> <div style=3D"margin:0pt"><font face=3D"Calibri,sans-serif" size=3D"2"><spa= n style=3D"font-size:11pt">Georgia Gwinnett College</span></font></div> <div style=3D"margin:0pt"><font face=3D"Calibri,sans-serif" size=3D"2"><spa= n style=3D"font-size:11pt">678-407-5093</span></font></div> <div style=3D"margin:0pt"><font face=3D"Calibri,sans-serif" size=3D"2"><spa= n style=3D"font-size:11pt">www.ggc.edu</span></font> </di= v> </span></div> </div> </div> </body> </html> --_000_97c686f412944d9f80995124b7d7f9b7BN1PR04MB170namprd04pro_--
On Thu, Dec 12, 2013 at 04:06:26AM +0000, Allen Belletti wrote:
Hi All,
Ever since moving from oVirt 3.1 (with Fedora image-based nodes) to oVirt 3.3 (and now 3.3.1) with CentOS 6.4 (now 6.5) nodes, I've been having a serious problem with our Windows guests. To my knowledge, none of the Linux guests have ever been affected.
The problem appears when a Windows guest is rebooted. Occasionally this happens during maintenance work but more often as a result of Microsoft updates which require a reboot. The most recent batch of these that we allowed resulted in something like 35 of 40 Windows guests losing networking.
What we see is that the VirtIO Ethernet Adapter is enabled but shows no evidence of actually being connected to the network. The MAC never appears in our switches, etc. The solution is to connect to the guest via console and manually disable, then enable, the NIC. Problem solved.
I've found at least two other references to this issue:
http://forum.proxmox.com/threads/11160-Windows-2008-R2-Server-Standard-Editi... (exactly our issue)
http://forum.proxmox.com/threads/16550-Windows-server-2012-blue-screen-virti... (similar, though we never see a crash)
Needless to say, this is super annoying. Right now it seems my options seem to be:
1. Implement a script to reset the NIC as suggested in the first link.
2. Revert to e1000 but not sure how much that will hurt performance and/or whether it will limit us to 1 Gbps throughput.
Has anyone experienced this? Would I likely have better luck on the VirtIO list? We've been running VirtIO Ethernet 61.63.103.3000 from virtio-win-0.1-65.iso but I just now found 61.65.104.7400 included in virtio-win-0.1-74.iso. Perhaps that will help although I don't see anything relevant in the changelog.
Which version of the host kernel exposes this? Which version (in ovirt-3.1) did not? Would you copy your qemu command line? I hope that Gal (CCed) and his friends can help if they get this info.
participants (2)
-
Allen Belletti -
Dan Kenigsberg