Created attachment 852660 [details] vdsm log Description of problem: Thread-87::ERROR::2014-01-20 10:01:58,535::sampling::355::vm.Vm::(collect) vmId=`84a46fd5-476e-46e8-b971-b92ac543066f`::Stats function failed: <AdvancedStatsFunction _highWrite at 0x27b41b8> Traceback (most recent call last): File "/usr/share/vdsm/sampling.py", line 351, in collect statsFunction() File "/usr/share/vdsm/sampling.py", line 226, in __call__ retValue = self._function(*args, **kwargs) File "/usr/share/vdsm/vm.py", line 509, in _highWrite if not vmDrive.blockDev or vmDrive.format != 'cow': AttributeError: 'Drive' object has no attribute 'format' How reproducible: 100% Actual results: Attribute error Expected results: No error
Version: vdsm-4.13.0-11.el6.x86_64
(In reply to Meital Bourvine from comment #0) > > How reproducible: > 100% We know that this happens when you upgrade from old version of rhev, because the revovery file format did change, and newer vdsm version do not validate old recovery files properly. See bug 994534. How do you reproduce this?
It happened to someone from the useres list, he claims that it started after live storage migration failure.
(In reply to Meital Bourvine from comment #3) > It happened to someone from the useres list, he claims that it started after > live storage migration failure. Please add a link to the post from the user list.
(In reply to Nir Soffer from comment #4) > (In reply to Meital Bourvine from comment #3) > > It happened to someone from the useres list, he claims that it started after > > live storage migration failure. > > Please add a link to the post from the user list. http://lists.ovirt.org/pipermail/users/2014-January/019951.html
Setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.
Nir, any update? Isn't this solved already?
There are multiple issues here: 1. Error when sample a drive without a "format" attribue I have a patch that avoid the extra logging in this case; http://gerrit.ovirt.org/22551, and it is even acked by Dan, but Federico correctly detected that this is not the right fix. The real issue is we should never have such drive. This issue will be fixed when http://gerrit.ovirt.org/21036 is ready. 2. If we look at the reporter logs in the mailing list, we see another error about disks that livrit does not recognize, also repeated in the logs. Having such error cause sampling to fail for all disks on the vm, probably leading to paused vm. I have this patch that improve error handling in this case: http://gerrit.ovirt.org/22575, which should be ported to master. 3. The real issue - why we have invalid disks during migration, is still not understood.
*** This bug has been marked as a duplicate of bug 1059482 ***