[fedora-virt] virtio cache mode and windows XP bluescreens

[Tom Horsley]

> > None of my CPUs are showing over 1% utilization and gkrellm
> > is showing only 2.0M disk write rate, so it sure seems like
> > all the components involved are spending more time just
> > waiting than anything else.
> 
> We need more details - guest/host versions, whether you use virtio or 
> ide, in case of virtio, what's the win pv version, etc.

Here's the disk in the KVM xml definition:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/zooty/images/winxppro.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>

So I'm using virtio. I tried mounting the virtio-win-0.1-15.iso in
the CDROM and asking XP to upgrade the disk driver, but it said the
on on the CD was not newer and did no upgrade. (But see below - maybe
I should have been upgrading the SCSI controller driver instead?)

But looking at the device manager in the XP machine gives me
pause. The Disk drives themselves say they are Redhat VirtIO SCSI disks
but are using a Microsoft provided driver 5.1.2535.0 dated 7/1/2001.
Should the disk drives themselves be on a different driver?

The SCSI controller inside the XP machine says Redhat VirtIO SCSI
and has a driver 5.3.0.17241 dated 10/10/2009.

That seems suspiciously old.

Also the disk image is probably the slowest possible image.
It is a qcow2 image, with a qcow2 backing file (so I can clone the
machine with different copies from the same backing file).

The write speed I calculated with "sdelete -c" running inside the
VM filling up the image file with zeroes was:

-rw-r--r-- 1 qemu qemu 3538087424 Nov 12 16:48 winxppro.img

-rw-r--r-- 1 qemu qemu 9181790208 Nov 12 19:49 winxppro.img

3 hours managed to write 5643702784 bytes
31,353,904.36 bytes per minute
522,565.07 bytes per second

It took about 8 hours to fill the unused 16 GB of the 20GB file
image with zeroes :-). I swear the last time I did it (probably around
6 months ago) it only took 5 hours (still pretty slow, mind you).

> cache=off and cache=writeothrough are safe and pretty much bugfree so I 
> doubt the root cause is there. In addition, latest qcow2 code should 
> perform relatively good, so please provide more details

It would not surprise me to find I have something misconfigured.

Also I note that the disk drive properties inside windows
has some performance settings available:

  ( ) Optimize for quick removal

  (*) Optimize for performance

      [ ] Enable write cacheing

Should any of those settings inside Windows be different?