From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm-77 Excessive Disk Access causes real time clock hang! Date: Sun, 26 Apr 2009 13:46:15 +0300 Message-ID: <49F43B77.4080102@redhat.com> References: <49F1DAF5.2060805@rdsoftware.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Erik Rull Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57534 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbZDZKqU (ORCPT ); Sun, 26 Apr 2009 06:46:20 -0400 In-Reply-To: <49F1DAF5.2060805@rdsoftware.de> Sender: kvm-owner@vger.kernel.org List-ID: Erik Rull wrote: > Hi all, > > I'm running kvm-77 and windows xp as guest. When I start the > defragmentation of the virtualized drive within the windows guest > (well this is not a fine way, but it should work :-)), the real time > clock starts hanging - I recognized that because some underlying > hardware with own timers began to run out of synchronization. I did > some research, took a stopwatch and measured against the system time. > During the measurement of ~ 30 seconds I got a difference to the linux > time (I just called "watch -n 1 date" which should come from the > mainboard system time, doesn't it?) of ~10 seconds! This was the > biggest difference I could measure, sometimes it was a little bit less. > > What's happening here? I reduced the io priority and the guest process > priority to a very low one - it didn't help! > > Oh - I'm running the stuff on an Intel Core2Duo T5600 @ 1.83GHz with 2 > Gig of RAM (Windows gets 1.5 Gig), the disk is an SATA with 40 Gigs. Are you using qcow2? In some cases qcow2 will stall the guest cpu. Note that defragmenting the guest drive may cause the qcow2 file to fragment even more, and will certainly increase its size. I recommend only defragmenting when using raw storage. -- error compiling committee.c: too many arguments to function