Re: [ovirt-users] Can't remove snapshot

On 17/02/16 11:14 -0500, Greg Padgett wrote: > On 02/17/2016 03:42 AM, Rik Theys wrote: >> Hi, >> >> On 02/16/2016 10:52 PM, Greg Padgett wrote: >>> On 02/16/2016 08:50 AM, Rik Theys wrote: >>>> From the above I conclude that the disk with id that ends with >>> Similar to what I wrote to Marcelo above in the thread, I'd recommend >>> running the "VM disk info gathering tool" attached to [1]. It's the >>> best way to ensure the merge was completed and determine which image is >>> the "bad" one that is no longer in use by any volume chains. >> >> I've ran the disk info gathering tool and this outputs (for the affected >> VM): >> >> VM lena >> Disk b2390535-744f-4c02-bdc8-5a897226554b >> (sd:a7ba2db3-517c-408a-8b27-ea45989d6416) >> Volumes: >> 24d78600-22f4-44f7-987b-fbd866736249 >> >> The id of the volume is the ID of the snapshot that is marked "illegal". >> So the "bad" image would be the dc39 one, which according to the UI is >> in use by the "Active VM" snapshot. Can this make sense? > > It looks accurate. Live merges are "backwards" merges, so the merge > would have pushed data from the volume associated with "Active VM" > into the volume associated with the snapshot you're trying to remove. > > Upon completion, we "pivot" so that the VM uses that older volume, and > we update the engine database to reflect this (basically we > re-associate that older volume with, in your case, "Active VM"). > > In your case, it seems the pivot operation was done, but the database > wasn't updated to reflect it. Given snapshot/image associations e.g.: > > VM Name Snapshot Name Volume > ------- ------------- ------ > My-VM Active VM 123-abc > My-VM My-Snapshot 789-def > > My-VM in your case is actually running on volume 789-def. If you run > the db fixup script and supply ("My-VM", "My-Snapshot", "123-abc") > (note the volume is the newer, "bad" one), then it will switch the > volume association for you and remove the invalid entries. > > Of course, I'd shut down the VM, and back up the db beforehand.

> "Active VM" should now be unused; it previously (pre-merge) was the > data written since the snapshot was taken. Normally the larger actual > size might be from qcow format overhead. If your listing above is > complete (ie one volume for the vm), then I'm not sure why the base > volume would have a larger actual size than virtual size. > > Adam, Nir--any thoughts on this? There is a bug which has caused inflation of the snapshot volumes when performing a live merge. We are submitting fixes for 3.5, 3.6, and master right at this moment.