(In reply to comment #0)
> See #659301
> 
> VDSM is receiving multiple ENOSPACE errors ( in error) and extend LVM
> accordingly but does so past the max vDisk size.

To handle this issue we need:
1 - to know the disk max size.
    * We can have RHEVM report the max disk size (on the vm creation)
    *  We can check it ourselves using qemu-image 
2 - to understand what is the current disk size.  This is not that trivial, the 
    actual disk size often pass the disk size allocated to the VM, since the 
    image inflates during time & snapshots. In addition what counts is the size 
    of the disk as viewed by the guest.
    * We can add this logic between VDSM & RHEV-Agent but there are 2 issues with 
    such approach:
    - the mapping between the internal disk viewed by the guest and the 
      external needs some digging.
    - Another issue relates to security - do we count on the guest to report this 
      issue?

But still it does not solve BZ#659301.
On the other hand once BZ#659301 is solved the need to handle this BZ is gone.

(In reply to comment #3)
> (In reply to comment #0)
> > See #659301
> > 
> > VDSM is receiving multiple ENOSPACE errors ( in error) and extend LVM
> > accordingly but does so past the max vDisk size.
> 
> To handle this issue we need:
> 1 - to know the disk max size.
>     * We can have RHEVM report the max disk size (on the vm creation)
>     *  We can check it ourselves using qemu-image 

We already have that information

> 2 - to understand what is the current disk size.  This is not that trivial, the 
>     actual disk size often pass the disk size allocated to the VM, since the 
>     image inflates during time & snapshots. In addition what counts is the size 
>     of the disk as viewed by the guest.

Size of the disk as viewed by the guest is equal to what you defined as "disk max size" and in any event is irrelevant here.
It is true that the qemu file can grow beyond the VDisk size, but we should probably limit this to be at most 150%.  An image growing beyond this is clearly a qemu bug which should be resolved asap.
Also, we need to warn user when crossing even 80% that it is recommended to convert image to raw (seeing as no disk space is saved and performance is degraded), but that is another RFE.

>     * We can add this logic between VDSM & RHEV-Agent but there are 2 issues
> with 
>     such approach:
>     - the mapping between the internal disk viewed by the guest and the 
>       external needs some digging.
>     - Another issue relates to security - do we count on the guest to report
> this 
>       issue?

As stated above, totally irrelevant.

> 
> But still it does not solve BZ#659301.
> On the other hand once BZ#659301 is solved the need to handle this BZ is gone.

The place to limit this (assuming we go for the 150% heuristic is in the storage code or before ever calling extend).

Also, need to support changing disk size -
Currently, users can change the disk size and we are oblivious to this except that reported size in RHEVM is incorrect and our MD is also out of date.
If we start limiting size then users will only be able to increase size of preallocated disks.

we cannot block max to disk size.
need to make sure we handle redundant enospace events
clean enospace events from queue before 'cont'?

Verified on VDSM version: vdsm-4.9-63.el6.x86_64
All VMs with Windows OS created thinly-provisioned over iSCSI.
All got lv size which is not above 3G.
After discuss with Danken, the size of the lv for each VM got bigger  - Didn't see that issue used that vdsm ver.