On Tue, Feb 02, 2016 at 11:14:01AM -0500, John Ferlan wrote:
On 02/02/2016 08:30 AM, Pavel Hrdina wrote:
On Tue, Feb 02, 2016 at 09:11:51AM +0100, Ján Tomko wrote:
On Mon, Feb 01, 2016 at 03:29:53PM -0500, John Ferlan wrote:
Modify the regex for the 'devices' (a/k/a 'extents') from "(\\S+)" (e.g., 1 or more) to "(\\S*)" (e.g., zero or more).
Then for any "thin" lv's found, mark the volume as a sparse volume so that the volume wipe algorithm doesn't work.
Since a "thin" segtype has no devices, this will result in any "thin" lv part of some thin-pool within a volume group used as a libvirt pool to be displayed as a possible volume to use.
A thin pool is another layer on top of some of the LVs in the VG. I think it deserves a separate pool type.
I must agree with Jan, and also already wrote the same for v2 patch. The thin pool and thin LV shouldn't be mixed with normal logical pool even they share the same VG.
If LVM allows it, then who are we to say it cannot or shouldn't work or how it should be configured?
Even if they are mixed in the same VG, we could show the "thick" LVs in the type='logical' pool and the thin ones in type='thin'.
Thin pools were introduced in LVM2 (2.02.89) according to what I've found. That's a few releases behind the 2.02.132 I have on my f23 laptop. Nothing in the description creating a thin-pool requires it's own volume group although sure some "best practices" indicate creating vg's as the container for a thin-pool.
I can certainly understand and agree in principle to creating a "strong preference" to have a thin-pool be a libvirt pool because it simplifies things such as allocated/capacity management and physical device source listing.
This is my reasoning - with all the thick and thin volumes grouped together, having free space in one does not mean there is free space for another.
So should I assume then the desire from the review viewpoint is to not support thin lv's at this point in time?
s/time/code/ But I cannot speak for the silent majority.
And that would be because we want them to be configured a specific way? FWIW: if someone did that - we still won't be able to support it without this patch.
How so? This patch displays the thin ('V') volumes in type='logical' pools. With a new pool type, the 'logical' pool could keep ignoring the thin pools and volumes, just like we skip directories in 'fs' pools.
Any thoughts on the VIR_STORAGE_VOL_LOGICAL*_REGEX's? (depending on the answer to the prior question with the obvious change of using S+ instead of S* for devices)?
They do look more readable to me. Jan