Bug 1214342
Summary: | After a failed snapshot, Live Snapshot Merge operation fails | ||||||
---|---|---|---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Kevin Alon Goldblatt <kgoldbla> | ||||
Component: | General | Assignee: | Ala Hino <ahino> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Aharon Canan <acanan> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.5.1 | CC: | acanan, ahino, alitke, amureini, bugs, gklein, gpadgett, lpeer, lsurette, nsoffer, rbalakri, Rhev-m-bugs, srevivo, tnisan, v.astafiev, ykaul, ylavi | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-06-05 11:47:10 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Kevin Alon Goldblatt
2015-04-22 13:38:52 UTC
Created attachment 1017453 [details]
engine, server, vdsm and libvirt logs
Adding logs
NOTE THAT THERE IS A 3 HOUR TIME DIFFERENCE BETWEEN THE ENGINE AND HOST LOGS
Adam, can you take a look please? Ok, I think I finally understand what's happening in this bug: During live storage migration, we create an automatic snapshot to reduce the amount of data that the qemu process must synchronize. Thread-118033::DEBUG::2015-04-21 20:30:34,918::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'Volume.create' in bridge with {u'preallocate': 2, u'volFormat': 4, u'srcImgUUID': u'1c9b5c2e-23ea-480c-b67b-50b969faf021', u'volumeID': u'63335b3b-6d82-446c-bb16-4ed9a6b20207', u'imageID': u'1c9b5c2e-23ea-480c-b67b-50b969faf021', u'storagepoolID': u'6d96f52d-d791-4f66-83bd-2553ca0f3012', u'storagedomainID': u'fd8aa916-0b31-4d2e-99ef-f218967e93e1', u'desc': u'', u'diskType': 2, u'srcVolUUID': u'c2a1254b-58dd-4d4c-ac0d-275093c99d05', u'size': u'3221225472'} Part of creating the snapshot volume is to mark the old leaf as internal: See blockVolume.BlockVolume._create() volParent.clone(volPath, volFormat) self.setInternal() Some time later we experience a failure to access storage 5ace41e8-feb4-43e0-8f47-5a5281001322::ERROR::2015-04-21 20:33:11,725::task::866::Storage.TaskManager.Task::(_setError) Task=`5ace41e8-feb4-43e0-8f47-5a5281001322`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/storage/task.py", line 334, in run return self.cmd(*self.argslist, **self.argsdict) File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper return method(self, *args, **kwargs) File "/usr/share/vdsm/storage/sp.py", line 1821, in createVolume desc=desc, srcImgUUID=srcImgUUID, srcVolUUID=srcVolUUID) File "/usr/share/vdsm/storage/sd.py", line 430, in createVolume preallocate, diskType, volUUID, desc, srcImgUUID, srcVolUUID) File "/usr/share/vdsm/storage/volume.py", line 435, in create srcVolUUID, volPath) File "/usr/share/vdsm/storage/blockVolume.py", line 159, in _create addTags=mdTags) File "/usr/share/vdsm/storage/lvm.py", line 1232, in changeLVTags (lvname, ", ".join(addTags), ", ".join(delTags), err[-1])) LogicalVolumeReplaceTagError: Replace Logical Volume tag error: (u'lv: `fd8aa916-0b31-4d2e-99ef-f218967e93e1/63335b3b-6d82-446c-bb16-4ed9a6b20207` add: `PU_c2a1254b-58dd-4d4c-ac0d-275093c99d05, MD_10, IU_1c9b5c2e-23ea-480c-b67b-50b969faf021` del: `OVIRT_VOL_INITIALIZING` ( Cannot process volume group fd8aa916-0b31-4d2e-99ef-f218967e93e1)',) This causes the createVolume task to fail and start recovery 5ace41e8-feb4-43e0-8f47-5a5281001322::DEBUG::2015-04-21 20:33:11,725::task::885::Storage.TaskManager.Task::(_run) Task=`5ace41e8-feb4-43e0-8f47-5a5281001322`::Task._run: 5ace41e8-feb4-43e0-8f47-5a5281001322 () {} failed - stopping task Part of recovery is supposed to fix the parent volume (making it a leaf again) See parentVolumeRollback() But since storage cannot be accessed, recovery fails 5ace41e8-feb4-43e0-8f47-5a5281001322::ERROR::2015-04-21 20:33:11,812::task::866::Storage.TaskManager.Task::(_setError) Task=`5ace41e8-feb4-43e0-8f47-5a5281001322`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/storage/task.py", line 403, in run return function(self.task, *argslist) File "/usr/share/vdsm/storage/volume.py", line 317, in parentVolumeRollback pvol.prepare() File "/usr/share/vdsm/storage/volume.py", line 764, in prepare if not self.isLegal(): File "/usr/share/vdsm/storage/volume.py", line 700, in isLegal legality = self.getMetaParam(LEGALITY) File "/usr/share/vdsm/storage/volume.py", line 918, in getMetaParam meta = self.getMetadata() File "/usr/share/vdsm/storage/blockVolume.py", line 606, in getMetadata raise se.VolumeMetadataReadError("%s: %s" % (metaId, e)) VolumeMetadataReadError: Error while processing volume meta data: ("('fd8aa916-0b31-4d2e-99ef-f218967e93e1', 12): Internal block device read failure: 'name=/dev/fd8aa916-0b31-4d2e-99ef-f218967e93e1/metadata, offset=6144, size=512'",) The image is now left without a leaf volume in the chain. Later we attempt a live merge. Thread-118301::DEBUG::2015-04-21 20:37:13,728::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.merge' in bridge with {u'topVolUUID': u'cf807726-3843-47e1-bf5b-ff0e81d51519', u'vmID': u'64b9a769-753a-4a51-9741-0f93f3b4f060', u'drive': {u'domainID': u'fd8aa916-0b31-4d2e-99ef-f218967e93e1', u'volumeID': u'c2a1254b-58dd-4d4c-ac0d-275093c99d05', u'poolID': u'6d96f52d-d791-4f66-83bd-2553ca0f3012', u'imageID': u'1c9b5c2e-23ea-480c-b67b-50b969faf021'}, u'bandwidth': u'0', u'jobUUID': u'76c42850-9bad-4bfc-8867-e33b921c9995', u'baseVolUUID': u'2c6abcc8-4a7f-4f7c-bdfa-c1d1430f7a56'} The merge starts and libvirt finishes all of it's work and it's time to synchronize the new chain to storage. See LiveMergeCleanupThread and imageSyncVolumeChain But this fails because we cannot lock the image: Thread-118305::ERROR::2015-04-21 20:37:15,505::task::866::Storage.TaskManager.Task::(_setError) Task=`ade72a05-082e-462b-b3d8-d27127d57604`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 45, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 1839, in imageSyncVolumeChain rm.LockType.shared): File "/usr/share/vdsm/storage/resourceManager.py", line 523, in acquireResource raise se.ResourceAcqusitionFailed() ResourceAcqusitionFailed: Could not acquire resource. Probably resource factory threw an exception.: () Which happens because Image.getChain() cannot find the leaf volume. Thread-118305::ERROR::2015-04-21 20:37:15,476::image::201::Storage.Image::(getChain) There is no leaf in the image 1c9b5c2e-23ea-480c-b67b-50b969faf021 Thread-118305::WARNING::2015-04-21 20:37:15,478::resourceManager::591::Storage.ResourceManager::(registerResource) Resource factory failed to create resource 'fd8aa916-0b31-4d2e-99ef-f218967e93e1_imageNS.1c9b5c2e-23ea-480c-b67b-50b969faf021'. Canceling request. Traceback (most recent call last): File "/usr/share/vdsm/storage/resourceManager.py", line 587, in registerResource obj = namespaceObj.factory.createResource(name, lockType) File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createResource lockType) File "/usr/share/vdsm/storage/resourceFactories.py", line 122, in __getResourceCandidatesList imgUUID=resourceName) File "/usr/share/vdsm/storage/image.py", line 202, in getChain raise se.ImageIsNotLegalChain(imgUUID) ImageIsNotLegalChain: Image is not a legal chain: (u'1c9b5c2e-23ea-480c-b67b-50b969faf021',) The merge job ends without updating anything and engine treats this as a live merge failure. Sadly, the merge actually did complete according to libvirt and qemu but we are now out of sync. I'd like to note that using a garbage collection approach instead of rollbacks would resolve this problem since the bad state would be cleaned up as soon as storage comes back online. We will have this in place as part of my SPM removal work :) I'm not sure if there's a good way to fix this problem in 3.5.x. It would be far too invasive to rerun recoveries when they fail with exceptions. The patch at http://gerrit.ovirt.org/45387 makes sure we handle errors when running imageSyncVolumeChain. This will correct some of the problematic behavior by not allowing the live merge job to resolve until imageSyncVolumeChain completes successfully. It will not prevent the image from being corrupted by the interrupted createVolume operation though. As noted in comment 3, the issue here isn't LSM, it's the failure in taking a snapshot. While the reported scenario indeed involves LSM, it may happen with any failed attempt to create a snapshot (regardless of its "liveliness"), followed by a live merge. Setting priority to medium as this is an edge case of an edge case. Adam - could you please provide a manual procedure to recover from such a corruption? There are several recovery actions which may or may not have been executed to the only real way to recover from this is to examine logs and the actual storage. For this very specific case the procedure is: 1. Identify the current leaf volume. It will be the same volume that was the leaf prior to creating the failed snapshot. 2. Modify the volume metadata on storage changing VOLTYPE=INTERNAL to VOLTYPE=LEAF For attached and connected file-based domains, the metadata is located in /rhev/data-center/<POOL-ID>/<DOMAIN-ID>/images/<IMAGE-ID>/<VOLUME-ID>.meta For block domains, I don't believe we have a tool to assist with modifying the metadata at this time. this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA. oVirt 4.0 beta has been released, moving to RC milestone. oVirt 4.0 beta has been released, moving to RC milestone. Should this be on MODIFIED or ON_QA? Neither; I still didn't investigate As explained in comments 3 and 7, this is a double (if not triple) negative flow, and we don't really have a good solutions for it on top of the patches already provided. |