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

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

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.

Quoted 3 lines

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?

Hi Avi,

Quoted 4 lines · Avi Kivity

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

Quoted 1 line

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?

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

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

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

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