Hi, Are we sure that this is fixed for 4.0.5? Failed to verify with rhevm-4.0.5.5-0.1.el7ev.noarch. I did add some vms with different "states" to the test but basically the same: 1. Have rhevm-3.6.9.2-0.1.el6.noarch on rhel 6.8. 2. Created 5 pairs of vms, for each per one vm is left up and the other down before the upgrade (didn't think this should effect this scenario but tried it nonetheless): pair a. snapshot with memory -> preview -> commit -> remove snapshot (snapshot points to 'Active') pair b. snapshot with memory -> preview -> commit (DID NOT remove snapshot) pair c. live snapshot without memory -> preview -> commit -> remove snapshot (snapshot points to 'Active') paird d. live snapshot without memory -> preview -> commit (DID NOT remove snapshot) pair e. normal snapshot (vm is down). 3. backup the engine. 4. re provision engine slave with rhel-7.2 5. install ovirt-engine-setup-4.0.5.5-0.1.el7ev.noarch and all other dependencies. 6. restore engine DB with backup file from (3). 7. engine-setup. Got same message as reporter, see attached log and DB dumps for all the information.
Created attachment 1218158 [details] log and DB dumps
(In reply to sefi litmanovich from comment #1) > Hi, Are we sure that this is fixed for 4.0.5? The fix is there but apparently there's a bug in it. You created a nice test! is it possible for you to manually modify the script /usr/share/ovirt-engine/dbscripts/upgrade/04_00_0140_convert_memory_snapshots_to_disks.sql right before the run? It would be great time-saver to test it with the following line after line 59 in that script: AND length(memory_volume) > 0
(In reply to Arik from comment #3) (I'm asking that after I validated that with this modification the reported issue is resolved on the attached db dump. I'm asking that in order to see that there are no other cases which are in the tested flow that the proposed fix won't cover)
I changed line 59 as you asked in comment 3 and setup succeeded as you expected. Env is back up with all the vms and their snapshots in the same state they were before the backup->upgrade flow.
Verified with rhevm-4.0.6-0.1.el7ev.noarch according to the steps mentioned in comment#1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0043.html