Virtio-Win block driver with Windows Server 2012 and libvirt

Latest response

Hello -

I have a Windows Server 2012 virtual machine running as a RHEL guest.  This one is in a RHEL KVM environment, managed with virt-manager.  RHEV is not installed anywhere at this site.   Looking at the Windows Event Viewer, I see occasional warnings with text similar to this:

The IO operation at logical block address 40028 for Disk 2 was retried

Although block number 40028 is commonly referenced, other block numbers range all over the place.  I see an average of maybe a couple of these warnings every day.  There were around 10 on 2/23, none 2/24, 2 on 2/25, 2 so far today. 

In the old days, before we had software pretending to be hardware, this generally meant a disk may have had some bad blocks.  But now ... ?

Here are the layers at this site:

From the Windows VM point of view, looking at Driver Details for the Red Hat VirtIO SCSI Disk Device, I see two files named disk.sys and partmgr.sys.  These must be standard Microsoft files. 

The viostor.sys driver in C:\Windows\System32 has a modify date of 7/6/2012, File version 60.63.103.2600.  Looking on the RHEL host, rpm -qa | grep virtio shows virtio-win-1.5.3-1.el6_3.noarch.  So I think I have the latest viostor driver inside that VM. 

The host is running RHEL 6.3.  It's a Dell PowerEdge R515 with a PERC H700i RAID controller and five 600 GB 15K RPM SAS drives.  These are RAIDed into one RAID 1 (mirror) set and a 3 drive RAID 5 set.  All storage is local on this host - no SAN or other shared storage here.  This host also has another VM running a firewall based on Fedora.

The virtual disks for this VM are LVM logical volumes. 

I have a couple of other Windows 2012 virtual machines in a RHEV environment at a different site with different hardware and these are not logging similar warnings. 

So my question - should I be concerned about these warnings and how do I find out the cause?  Why does this Windows driver need to retry IO operations sometimes?

Oh yes - from the host point of view -

dmesg | grep sda
dmesg | grep sdb, and
dmseg | grep /dev/mapper

all return nothing. 

thanks

- Greg Scott

Responses