Pushed a patch for the issue here: http://gerrit.ovirt.org/#/c/17599/

Now I see the following traceback in the logs:

Traceback (most recent call last):
  File "/usr/share/vdsm/clientIF.py", line 382, in teardownVolumePath
    res = self.irs.teardownImage(drive['domainID'],
  File "/usr/share/vdsm/vm.py", line 1343, in __getitem__
    raise KeyError(key)
KeyError: 'domainID'

Il 01/08/2013 14:10, Dan Kenigsberg ha scritto:
> On Thu, Aug 01, 2013 at 05:31:44AM -0400, Antoni Segura Puimedon wrote:
>> Looking at clientIF.py on the patch Michal pointed to, concretely on:
>> +    def removeVmFromMonitoredDomains(self, vmId):
>> +        for dom in self.domainVmIds:
>> +            #only take lock here to allow runVm to take the lock in-between
>> +            with self.domainVmIdsLock:
>> +                try:
>> +                    self.domainVmIds[dom].remove(vmId)
>> +                except ValueError:
>> +                    pass
>> +                else:
>> +                    if not self.domainVmIds[dom]:
>> +                        del self.domainVmIds[dom]
>> If there is no exception we will be deleting an element from a dictionary 
>> while
>> iterating it. This is dangerous and should be avoided. The fastest 
>> alternative
>> to implement would be that in the "else" we append dom to a list of 
>> domainsToRemove
>> and after the iteration we get a lock and remove all of them.
> Alternatively, I believe we could do without maintaining the
> domain->vmId mapping. I did not understand why having each VM hold its
> domains is not enough.
> The said patch has another problem - a single SIGSTOPped qemu process
> can block all SPM operations (in case its storage domain has become
> active again and we attempt to cont the VM).
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

vdsm-devel mailing list

Reply via email to