Bug 1308501 - Create a KBase for the manual fixup required if Live Merge fails in step 'DESTROY_IMAGE_CHECK'
Create a KBase for the manual fixup required if Live Merge fails in step 'DES...
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.3
Unspecified Unspecified
medium Severity high
: ovirt-3.6.6
: ---
Assigned To: Roman Hodain
rhev-docs@redhat.com
: Reopened
Depends On: 1302215 1306741
Blocks: 1306732
  Show dependency treegraph
 
Reported: 2016-02-15 07:13 EST by Yaniv Lavi
Modified: 2016-07-19 06:04 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1306741
Environment:
Last Closed: 2016-05-24 05:50:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixup script for the described situation (4.76 KB, text/x-vhdl)
2016-02-17 02:39 EST, Allon Mureinik
no flags Details
VM disk info gathering tool (1.76 KB, text/plain)
2016-02-17 18:28 EST, Greg Padgett
no flags Details
Fixup script for the described situation (updated) (5.78 KB, text/x-vhdl)
2016-02-18 18:14 EST, Greg Padgett
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2265011 None None None 2016-05-07 05:17 EDT

  None (edit)
Comment 1 Yaniv Lavi 2016-02-15 07:14:37 EST
I was mistaken, this can happen in 3.5 and needs a fix script in a kbase for that option, can you open one?
Comment 2 Yaniv Lavi 2016-02-15 07:15:07 EST
The script in the upstream bug.
Comment 3 Allon Mureinik 2016-02-17 02:39 EST
Created attachment 1127882 [details]
Fixup script for the described situation

Attaching the relevant script
Comment 5 Roman Hodain 2016-02-17 07:32:45 EST
(In reply to Yaniv Dary from comment #1)
> I was mistaken, this can happen in 3.5 and needs a fix script in a kbase for
> that option, can you open one?

I just want to confirm. This sql is only applicable if the VM has just one disk in the snapshot right? In case there is another disk in the same snapshot, the scrip cannot be used.

It is about the initial select 

    SELECT images.* INTO v_verify                                               
    FROM images                                                                 
    JOIN snapshots ON (images.vm_snapshot_id = snapshots.snapshot_id)           
    JOIN vm_static ON (snapshots.vm_id = vm_static.vm_guid)                     
    WHERE vm_static.vm_name = v_vm_name                                         
        AND snapshots.description = v_snapshot_name;                         

It lists a row for each image in the snapshot. We then call 
v_good_img := v_verify.image_guid

We always get the first image_guid which does not have to be the one we are looking for.

Also as this is intended for RHEV 3.5 we should modify the script as 3.5 DB doe snot contain any column images.volume_classification

        UPDATE images
            SET vm_snapshot_id = v_tmp.vm_snapshot_id,
                volume_classification = v_tmp.volume_classification,
                size = v_tmp.size,
                active = v_tmp.active,
                imagestatus = 1
            WHERE image_guid = v_good_img;
Comment 6 Greg Padgett 2016-02-17 18:24:31 EST
(In reply to Roman Hodain from comment #5)
> I just want to confirm. This sql is only applicable if the VM has just one
> disk in the snapshot right? In case there is another disk in the same
> snapshot, the scrip cannot be used.

Thanks, yes, I'll provide a version suitable for use with multiple disks.

> Also as this is intended for RHEV 3.5 we should modify the script as 3.5 DB
> doe snot contain any column images.volume_classification

Same for this--I'll either make one script that works for 3.5 and 3.6, or provide one for each version.
Comment 7 Greg Padgett 2016-02-17 18:28 EST
Created attachment 1128045 [details]
VM disk info gathering tool

I'm attaching Adam Litke's VM disk info gathering tool from the upstream bug, as it's a useful verification tool to show that the volume being removed from the db is truly not in use by any VMs.
Comment 8 Greg Padgett 2016-02-18 18:14 EST
Created attachment 1128341 [details]
Fixup script for the described situation (updated)

I updated the script to:
 - handle snapshots with multiple disks
 - maintain backward compatibility with 3.5

It now requires an additional parameter of the disk alias, thus params are:
  v_vm_name VARCHAR
  v_snapshot_name VARCHAR
  v_disk_alias VARCHAR
  v_removed_image_uuid VARCHAR

I also added a warning if it proceeds to check the child snapshot, so that if it fails to find any match, it will have at least hinted that it may be due to the image status (must be illegal) or parent image assignment.  Occasionally the image may have to be marked illegal by hand in order to proceed.

For backwards compatibility it will check for the existence of the volume_classification column before attempting to update it, thus it is compatible with both 3.5 and 3.6 schemas.
Comment 9 Yaniv Lavi 2016-02-29 07:27:08 EST
Any updates on this?
Comment 10 Roman Hodain 2016-04-20 04:31:53 EDT
Done:

Live Merge fails in step 'DESTROY_IMAGE_CHECK' 
https://access.redhat.com/solutions/2265011
Comment 11 Yaniv Lavi 2016-05-01 06:22:44 EDT
See article in comment #10.
Comment 14 Greg Padgett 2016-05-03 09:51:36 EDT
I can't access the article, but bug 1330715 resulted in an update to the instructions: the script should be removed after use.  If this isn't in the article, can we add it?

Here is text from one of the updated bug entries (bug 1302215#c16) about the removal:

===
For anyone that uses this workaround, note that it is best to remove the stored procedure after use.  Leaving it may cause trouble later on (especially if installed via a different dbuser than the rest of the engine database).

psql <dbname> -U <dbuser> -c 'DROP FUNCTION ovirt_repair_failed_merge(varchar, varchar, varchar, varchar)'
===
Comment 15 Roman Hodain 2016-05-07 05:17:30 EDT
(In reply to Greg Padgett from comment #14)
> I can't access the article, but bug 1330715 resulted in an update to the
> instructions: the script should be removed after use.  If this isn't in the
> article, can we add it?
> 
> Here is text from one of the updated bug entries (bug 1302215#c16) about the
> removal:
> 
> ===
> For anyone that uses this workaround, note that it is best to remove the
> stored procedure after use.  Leaving it may cause trouble later on
> (especially if installed via a different dbuser than the rest of the engine
> database).
> 
> psql <dbname> -U <dbuser> -c 'DROP FUNCTION
> ovirt_repair_failed_merge(varchar, varchar, varchar, varchar)'
> ===

Hi,

yes it is included.

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