Bug 1055437 - AttributeError: 'Drive' object has no attribute 'format'
Summary: AttributeError: 'Drive' object has no attribute 'format'
Keywords:
Status: CLOSED DUPLICATE of bug 1059482
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Nir Soffer
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-20 09:26 UTC by Meital Bourvine
Modified: 2016-02-10 19:36 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-26 19:50:59 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)
vdsm log (39.28 KB, text/x-log)
2014-01-20 09:26 UTC, Meital Bourvine
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 24234 0 master ABANDONED vm: Require format attribute for drives Never

Description Meital Bourvine 2014-01-20 09:26:34 UTC
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

Comment 1 Meital Bourvine 2014-01-20 10:13:28 UTC
Version:
vdsm-4.13.0-11.el6.x86_64

Comment 2 Nir Soffer 2014-01-20 14:18:12 UTC
(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?

Comment 3 Meital Bourvine 2014-01-20 14:24:36 UTC
It happened to someone from the useres list, he claims that it started after live storage migration failure.

Comment 4 Nir Soffer 2014-01-20 14:37:28 UTC
(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.

Comment 5 Meital Bourvine 2014-01-20 14:53:08 UTC
(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

Comment 6 Itamar Heim 2014-01-26 08:12:14 UTC
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.

Comment 7 Allon Mureinik 2014-01-26 08:54:33 UTC
Nir, any update?
Isn't this solved already?

Comment 8 Nir Soffer 2014-02-04 11:50:08 UTC
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.

Comment 9 Nir Soffer 2014-02-26 19:50:59 UTC

*** This bug has been marked as a duplicate of bug 1059482 ***


Note You need to log in before you can comment on or make changes to this bug.