[ovirt-users] Ovirt snapshot failing on one VM

[Steve Dainard]

Restarting vdsm and hosts didn't do anything helpful.

I was able to clone from latest snapshot, then live snapshot the new cloned
VM.

After upgrading engine to 3.4 and upgrading my hosts, I can now live
snapshot this VM.


*Steve *


On Thu, Apr 24, 2014 at 1:48 AM, Itamar Heim <iheim at redhat.com> wrote:

> On 04/23/2014 09:57 PM, R P Herrold wrote:
>
>> On Wed, 23 Apr 2014, Steve Dainard wrote:
>>
>>  I have other VM's with the same amount of snapshots without this problem.
>>> No conclusion jumping going on. More interested in what the best practice
>>> is for VM's that accumulate snapshots over time.
>>>
>>
>> For some real world context, we seem to accumulate snapshots
>> using our local approach, and are not that focused on, or
>> attentive about removing them.  The 'highwater mark' of 39, on
>> a machine that has been around since it was provisioned:
>> 2010-01-05
>>
>> [root at xxx backups]# ./count-snapshots.sh | sort -n | tail -3
>> 38 vm_64099
>> 38 vm_98036
>> 39 vm_06359
>>
>> Accumulating large numbers of snapshots seems more the
>> function of pets, than ephemeral 'cattle'
>>
>> I wrote the first paragraph without looking up the 'owners' of
>> the images. As I dereference the VM id's, all of the top ten
>> in that list turn out to be mailservers, radius servers, name
>> servers, and such, where the business unit owners chose not
>> (or neglect) to 'winnow' their herd.  There are no ephemeral
>> use units in the top ten
>>
>> -- Russ herrold
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
> please note there is a recommended limit of having no more than 500
> snapshots per block storage domain due to some LVM performance issues with
> high number of LVs. each disk/snapshot is an LV.
> NFS doesn't have this limitation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140425/64c17a3d/attachment-0001.html>