On 03/11/2010 04:19 PM, Anthony Liguori wrote:
But honestly, while I do understand your point, this feels like a hack
to work around shortcomings of an interface. So what we need to decide
is which criterion outweighs the other in practice.
If I understand the use case correctly, what this really boils down to
is that you want to create a growable image on top of a non-growable
device. The management tool then deals with growth using this interface.
I'm somewhat inclined to suggest that the proper way to support this
is to teach qemu how to grow the LVM volume like it would grow any
normal file.
Interesting. Could use a helper or helper.so, or a new block format
driver (block/lvm.c). Still, if management is actually interested in
the change, not just to grow the volume (perhaps to handle out-of-space,
or to check against a global disk low condition), the helper/driver then
needs to communicate with the management system, which is awkward.
I guess it's workable though.
--
error compiling committee.c: too many arguments to function
