Created attachment 956684 [details]
self explanatory screenshot

yes, it still is.

Yikes, this went out of my radar. Last I recall I was not able to reproduce it but I'll give it another try. I'm PTO tomorrow so it has to be on Monday.

Vladimir,

Assuming you can still reproduce this, is this only when customizing resources before creation or afterwards or both?

Zeeshan,
from what I can see it's just before creation.

Yay, at least now I can reproduce this.

(In reply to Zeeshan Ali from comment #10)
> Yay, at least now I can reproduce this.

Looking at the code, I'm a bit baffled by this. Still investigating..

Created attachment 1076051 [details]
libvirt-machine-props: Refresh pool after getting it

Somehow storage pool needs to be refreshed just prior to getting info
about it even though pool is refreshed at least once before in another
part of the code. Without this small patch, we get bogus info from the
pool and I'm stumped as to why.
    
This fixes the issue of insane max storage values at customization page of wizard.

Actually this turns out to be a libvirt issue:

virsh # vol-create gnome-boxes /tmp/volume.xml
Vol boxes-unknown-3 created from /tmp/volume.xml

virsh # pool-info gnome-boxes
Name:           gnome-boxes
UUID:           92060d87-c7c7-4b1b-9088-da996416e539
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       104.71 GiB
Allocation:     109.13 GiB
Available:      16.00 EiB

--------

This is reproducible with master provided the (qcow2) volume <capacity> is bigger than the available space in the pool

This is caused by 
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/storage/storage_driver.c;h=0494e5d7a0695612631a20ac09e92e67f0ef2c42;hb=HEAD#l1876 

1877     /* Update pool metadata ignoring the disk backend since
1878      * it updates the pool values.
1879      */
1880     if (pool->def->type != VIR_STORAGE_POOL_DISK) {
1881         pool->def->allocation += buildvoldef->target.allocation;
1882         pool->def->available -= buildvoldef->target.allocation;
1883     }

volume.xml is
<volume>
  <name>boxes-unknown-3</name>
  <capacity>21474836480</capacity> <!-- 20GB -->
  <target>
    <format type="qcow2"/>
    <permissions>
      <owner>1000</owner>
      <group>1000</group>
      <mode>744</mode>
    </permissions>
  </target>
</volume>

buildvoldef->target.allocation is 20GB, pool->def->available is < 20GB, so the substraction overflows, giving us the 16 EiB output. I guess buildvoldef->target.allocation should not be 20GB for a qcow2 volume ?

Also reproducible with libvirt-1.2.8-16.el7_1.

Upstream patches:
https://www.redhat.com/archives/libvir-list/2015-September/msg00906.html

Fixed upstream by:
commit 56a4e9cb613aff9cd6f828c0a9283fba55ac5951
Author:     Ján Tomko <jtomko>
CommitDate: 2015-09-29 10:45:01 +0200

    Update pool allocation with new values on volume creation
    
    Since commit e0139e3, we update the pool allocation with
    the user-provided allocation values.
    
    For qcow2, the allocation is ignored for volume building,
    but we still subtracted it from pool's allocation.
    This can result in interesting values if the user-provided
    allocation is large enough:
    
    Capacity:       104.71 GiB
    Allocation:     109.13 GiB
    Available:      16.00 EiB
    
    We already do a VolRefresh on volume creation. Also refresh
    the volume after creating and use the new value to update the pool.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1163091

git describe: v1.2.20-rc1-1-g56a4e9c

this was reproducible on libvirt-1.2.17-13.el7 as comment 13

Verified on libvirt libvirt-1.3.1-1.el7.x86_64 and PASSED

steps:

1. # virsh pool-info default
Name:           default
UUID:           3a9d8c79-3034-4dd0-9a6e-f4a165f3efc4
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       39.25 GiB
Allocation:     29.47 GiB
Available:      9.78 GiB


2. # cat vol.xml 
<volume>
<name>200GB_VOL</name>
<capacity>214748364800</capacity> 
<target>
<format type="qcow2"/>
<permissions>
<owner>1000</owner>
<group>1000</group>
<mode>744</mode>
</permissions>
</target>
</volume>


3. # virsh vol-create default vol.xml
Vol 200GB_VOL created from vol.xml


4. # virsh vol-info 200GB_VOL default
Name:           200GB_VOL
Type:           file
Capacity:       200.00 GiB
Allocation:     196.00 KiB


5. # virsh pool-info default
Name:           default
UUID:           3a9d8c79-3034-4dd0-9a6e-f4a165f3efc4
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       39.25 GiB
Allocation:     29.47 GiB
Available:      9.78 GiB   <==== this value is correct now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html