On Mon, 2010-12-13 at 22:12 +0200, Dor Laor wrote: > On 12/13/2010 09:42 PM, Manfred Heubach wrote: > > > > > > Gleb Natapov<gleb<at> redhat.com> writes: > > > >> > >> On Wed, Jul 28, 2010 at 12:53:02AM +0300, Harri Olin wrote: > >>> Gleb Natapov wrote: > >>>> On Wed, Jul 21, 2010 at 09:25:31AM +0300, Harri Olin wrote: > >>>>> Gleb Natapov kirjoitti: > >>>>>> On Mon, Jul 19, 2010 at 10:17:02AM +0300, Harri Olin wrote: > >>>>>>> Gleb Natapov kirjoitti: > >>>>>>>> On Thu, Jul 15, 2010 at 03:19:44PM +0200, Christoph Adomeit wrote: > >>>>>>>>> But one Windows 2008 64 Bit Server Standard is freezing regularly. > >>>>>>>>> This happens sometimes 3 times a day, sometimes it takes 2 days > >>>>>>>>> until freeze. The Windows Machine is a clean fresh install. > >>>>>>> I think I have seen same problem occur on my Windows 2008 SBS SP2 > >>>>>>> 64bit system, but a bit less often, only like once a week. > >>>>>>> Now I haven't seen crashes but only freezes with qemu on 100% and > >>>>>>> virtual system unresponsive. > >>>> Does sendkey from monitor works? qemu-kvm-0.11.1 is very old and this is > >>>> not total freeze which even harder to debug. I don't see anything > >>>> extraordinary in your logs. 4643 interrupt per second for 4 cpus is > >>>> normal if windows runs multimedia or other app that need hi-res timers. > >>>> Does your host swapping? Is there any chance that you can try upstream > > qemu-kvm? > >>> > >>> I tried running qemu-kvm from git but it exhibited the same problem > >>> as 12.x that I tried before, BSODing once in a while, running kernel > >>> 2.6.34.1. > >>> > >> That should be pretty stable config, although it would be nice if you > >> could try running in qemy-kvm.git head. > >> > >>> sample BSOD failure details: > >>> These two with Realtec nic and qemu cpu > >>> 0x00000019 (0x0000000000000020, 0xfffff88007e65970, > >>> 0xfffff88007e65990, 0x000000000502040f) > >>> 0x00000019 (0x0000000000000020, 0xfffff88007a414c0, > >>> 0xfffff88007a414e0, 0x000000000502044c) > >>> > >>> These are with e1000 and -cpu host > >>> 0x0000003b (0x00000000c0000005, 0xfffff80001c5d842, > >>> 0xfffffa60093ddb70, 0x0000000000000000) > >>> 0x0000003b (0x00000000c0000005, 0xfffff80001cb8842, > >>> 0xfffffa600c94ab70, 0x0000000000000000) > >>> 0x0000000a (0x0000000000000080, 0x000000000000000c, > >>> 0x0000000000000001, 0xfffff80001cadefd) > >>> > >> Can you attach screenshots of BSODs? Have you reinstalled your guests or > >> are you running the same images you ran in 11.x? > >> > >>> I'll see if I can analyze minidumps later. > >>> > >>> In addition to these there have been as many reboots that have been > >>> only logged as 'disruptive shutdown'. > >>> > >>> Right now I'm running the problematic guest under Xen > >>> 3.2.1-something from Debian to see if it works better. > >>> > >>> -- > >>> Harri. > >> > > Hello, > > > > is there a solution for that problem? I'm experiencing the same problems ever > > since I installed SBS 2008 on KVM. > > > > I was running the host with Ubuntu 10.04 but upgraded to 10.10 - mainly because > > of performance problems which were solved by the upgrade. > > > > After the upgrade the system became extremly unstable. It was crashing as soon > > as disk io and network io load was growing. 100% reproduceable with windows > > server backup to an iscsi volume. > > > > i had virtio drivers for storage and network installed (redhat/fedora 1.1.11). > > Which fedora/rhel release is that? > What's the windows virtio driver version? > > Have you tried using virt-manager/virhs instead of raw cmdline? > About e1000, some windows comes with buggy driver and an update e1000 > from Intel fixes some issues. > > > > At each BSOD I had the following line in the log of the guest: > > > > virtio_ioport_write: unexpected address 0x13 value 0x1 > > > > I changed the network interface back to e1000. What I experience now (and I had > > that a the very beginning before i switched to virtio network) are freezes. The > > guest doesn't respond anymore (doesn't answer to pings and doesn't interact via > > mouse/keyboard anymore). Host CPU usage of the kvm process is 100% on as many > > cores as there are virtual cpus (in this case 4). > > Sounds like an interrupt storm to me. Can you try to ping your VM? Anyway the best way to start debugging a stalled system is just to crash it with BSOD. For doing it you will need: - enable NMICrashDump (please see http://support.microsoft.com/kb/927069 for more information - enable Kernel Memory Dump (actually Complete is much better, but it can be too big) http://support.microsoft.com/kb/969028 - you only will need to type "nmi 0" in the qemu monitor to crash the system, when the system hangs next time. Best regards, Vadim. > > I'm a bit frustrated about this. I have 2 windows 2003 32bit, 1 windows xp and 3 > > linux guests (2x 32bit, 1x64 bit). They are all running without any problems > > (except that the windows xp guest cannot boot without an ntldr cd image). Only > > the SBS2008 guest regulary freezes. > > > > The host system has 2 Intel Xeon 5504, Intel Chipset 5500, Adaptec Raid 5805, 24 > > GB DDR3 RAM. > > > > I know there is a lack of detailed information right now. I first need to know > > if anybody is working on this or has similar problems. I can deliver minidumps, > > and any debugging information you need. > > > > I don't want to give up now. We will switch to Hyper-V if we cannot solve this, > > because we need a stable virtualization plattform for Windows Guests. I would > > like to use KVM it is so much more flexibel. > > > > Best regards > > Manfred > > > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
