Bug 1308501

I was mistaken, this can happen in 3.5 and needs a fix script in a kbase for that option, can you open one?

The script in the upstream bug.

Created attachment 1127882 [details]
Fixup script for the described situation

Attaching the relevant script

(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;

(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.

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.

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.

Any updates on this?

Done:

Live Merge fails in step 'DESTROY_IMAGE_CHECK' 
https://access.redhat.com/solutions/2265011

See article in comment #10.

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)'
===

(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.