Re: kvm-77 Excessive Disk Access causes real time clock hang!
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
