[ovirt-users] Can't remove snapshot
Rik Theys
Rik.Theys at esat.kuleuven.be
Thu Feb 18 09:37:12 UTC 2016
Hi,
On 02/17/2016 05:29 PM, Adam Litke wrote:
> 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.
I've executed the sql script and it seems to have worked. Thanks!
>> "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.
Which bug number is assigned to this bug? Will upgrading to a release
with a fix reduce the disk usage again?
Regards,
Rik
--
Rik Theys
System Engineer
KU Leuven - Dept. Elektrotechniek (ESAT)
Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee
+32(0)16/32.11.07
----------------------------------------------------------------
<<Any errors in spelling, tact or fact are transmission errors>>
More information about the Users
mailing list