Description of problem: Issue: Apr 6 00:00:03 hyper-1-01 vdsm vm.Vm ERROR vmId=`da316c1e-db3e-40cf-a067-90abd16c8903`::Stats function failed: <AdvancedStatsFunction _highWrite at 0x1a848f0>#012Traceback (most recent call last) :#012 File "/usr/share/vdsm/sampling.py", line 351, in collect#012 File "/usr/share/vdsm/sampling.py", line 226, in __call__#012 File "/usr/share/vdsm/vm.py", line 532, in _highWrite#012 File "/usr/share/vdsm/vm.py", line 2320, in extendDrivesIfNeeded#012AttributeError: 'Drive' object has no attribute 'format' http://lists.ovirt.org/pipermail/users/2013-December/018905.html may be helpful https://bugzilla.redhat.com/show_bug.cgi?id=1055437 is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1059482 Environment: RHEV 3.3 vdsm-4.13.2-0.13.el6ev.x86_64 on all hosts From the previously listed BZ: The problem is because the newer vdsm version configures libvirt to use paths of the form: /rhev/data-center/mnt/<mountpoint>/<sd uuid>/images/<disk uuid>/<img uuid> ^^^^^^^^^^^^^^^^ whereas the older vdsm used the form /rhev/data-center/<sp uuid>/<sd uuid>/images/<disk uuid>/<img uuid> ^^^^^^^^^ For VMs started under the new vdsm this is fine, but for VMs migrated from an older hypervisor, the libvirt XML, including the old-style paths is carried along. That means that the vdsm and libvirt paths are out of sync, causing the error above when vdsm attempts to query libvirt for information about the disk. Looking into "'Drive' object has no attribute 'format'" on bugzilla returns Migrating between older and newer RHEV-H images leads to flood "path /rhev/data-center/mnt/blockSD/<UUID>/images/<UUID>/<UUID> not assigned to domain" https://bugzilla.redhat.com/show_bug.cgi?id=1061621 which points to private solution 3.3.0-3 (no format attribute) VDSM workaround https://access.redhat.com/site/solutions/727423 which points to the public solution RHEV 3.3 - VMs get paused due to "no storage space error" https://access.redhat.com/site/solutions/727433 Version-Release number of selected component (if applicable): vdsm-4.13.2-0.13.el6ev.x86_64 RHEV-H build of 20140407.0.el6ev These versions should not exhibit the issue in https://access.redhat.com/site/solutions/727433 Customer is willing to perform the steps in this solution when they can get the downtime to be able to do so: https://access.redhat.com/site/solutions/727433
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0504.html