This is a bug to split out one element of the previous report https://bugzilla.redhat.com/show_bug.cgi?id=892269 - see https://bugzilla.redhat.com/show_bug.cgi?id=892269#c15 . We decided that bug was actually covering three different problems, and leading to confusion.

If you are in custom partitioning and you have a pre-existing LV, and there is empty space in that LV, you cannot edit VGs within that VG and make them larger - the 'Desired Capacity (MB)' spinbutton element incorrectly caps the maximum possible size. This applies both to LVs that already exist within the VG, and if you create a new mount point and it is created as a new LV within the existing VG: in both cases, what happens is you cannot make the LV any larger than its current size.

This is pretty easy to reproduce: the simplest reproducer is to set up a system where you have a VG with space within it, say a 14GB VG with a 6GB 'root' LV and a 2GB 'swap' LV. There is therefore 8GB of space remaining in the VG. But if you go to custom partitioning, select the 'root' VG and try to edit its size up to anything larger than 6000MB, anaconda will refuse. You can edit it *down* to a smaller size - say, 5000MB - but once you do so and hit 'Apply Changes', you cannot make it any larger even than the smaller size you just set. You can't edit it back to 6000MB, even.

The same applies if you hit the + button to create a new mount point for the proposed F18 install. It will be created as a new LV within the existing VG, if you have no or little unpartitioned space remaining, and again, you will not be able to edit it to be any size larger than the size it was created with.