kvm-77 Excessive Disk Access causes real time clock hang!

kvm-77 Excessive Disk Access causes real time clock hang!

[Erik Rull]

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.

Best regards,

Erik

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Marcelo Tosatti]

Erik,

On Fri, Apr 24, 2009 at 05:29:57PM +0200, 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.

Can you try kvm-85 with -rtc-td-hack option? kvm-84 added this option,
from Gleb (CC'ed), to reinject lost RTC interrupts.

> 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.
>
> Best regards,
>
> Erik

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Avi Kivity]

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

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Erik Rull]

Hi Avi,

Avi Kivity wrote:
> 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.

I don't think so. I created a partition on my host "real" harddrive and 
provided this partition to my windows guest.

If you have an idea, which virtualized drive system could be the fastest 
(except giving a complete disk to the guest), your comments are welcome :-)

Best regards,

Erik

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Avi Kivity]

Erik Rull wrote:
>> 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.
>
> I don't think so. I created a partition on my host "real" harddrive 
> and provided this partition to my windows guest.
>
> If you have an idea, which virtualized drive system could be the 
> fastest (except giving a complete disk to the guest), your comments 
> are welcome :-)
>
>

interface: virtio
cache: none
format: raw, using a partition or logical volume

What are you using?


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Erik Rull]

Hi Avi,

Avi Kivity wrote:
> interface: virtio
> cache: none
> format: raw, using a partition or logical volume
> 
> What are you using?

uhm, I'm not sure, I call qemu with:

qemu-system-x86_64 -usb -hda /dev/hda2 -m 1536 -net nic,macaddr=$MACADDR 
-net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -usbdevice tablet 
-boot c

The /dev/hda2 is NTFS formatted - does this make sense, because you wrote 
sth. with raw...
Maybe another file system would be faster? Or is it ignored by the guest 
system?

Best regards,

Erik

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Avi Kivity]

Erik Rull wrote:
> Hi Avi,
>
> Avi Kivity wrote:
>> interface: virtio
>> cache: none
>> format: raw, using a partition or logical volume
>>
>> What are you using?
>
> uhm, I'm not sure, I call qemu with:
>
> qemu-system-x86_64 -usb -hda /dev/hda2 -m 1536 -net 
> nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor 
> stdio -usbdevice tablet -boot c
>
> The /dev/hda2 is NTFS formatted - does this make sense, because you 
> wrote sth. with raw...
> Maybe another file system would be faster? Or is it ignored by the 
> guest system?

The file system is the guest's business.  Instead of '-hda /dev/hda2', try

  -drive file=/dev/hda2,cache=none


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Erik Rull]

Hi Avi,

Avi Kivity wrote:
> Erik Rull wrote:
> The file system is the guest's business.  Instead of '-hda /dev/hda2', try
> 
>  -drive file=/dev/hda2,cache=none

great!
cache=off worked - none caused an error.

The Timing problem is still present but the XP system is now much more 
interactive during file access (copy / defrag,...)

I will try out the 84 kvm with the irq-reinjection.

Best regards,

Erik

Re: kvm-77 Excessive Disk Access causes real time clock hang!

[Erik Rull]

Hi Avi,

Avi Kivity wrote:
> Erik Rull wrote:
> The file system is the guest's business.  Instead of '-hda /dev/hda2', try
> 
>  -drive file=/dev/hda2,cache=none

great!
cache=off worked - none caused an error.

The Timing problem is still present but the XP system is now much more
interactive during file access (copy / defrag,...)

I will try out the 84 kvm with the irq-reinjection.

Best regards,

Erik