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 <ih...@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@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@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. >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users