[libvirt] [PATCH] introducing <source> <name> (for logical storage pools)
David Lively
dlively at virtualiron.com
Fri Aug 8 19:17:52 UTC 2008
Hi Folks -
This small patch is a proposed prerequisite for the storage pool
discovery patch I submitted last week.
Daniel B proposed having storage pool discovery return a bunch of XML
storage <source> elements, rather than full <pool> elements (which
contain "target-dependent" details like the local pool name and device
or mount path -- things which don't need to be decided unless/until the
pool is defined).
I like his suggestion a lot, and I think it addresses the final
API-definition problem keeping storage pool discovery out of libvirt.
But ... it doesn't quite work for logical storage pools because those
are created from the <pool> <name> element (which is the same as the
volume group name).
This patch introduces a new <source> element <name>, which is
distinct
from the pool name. <name> is used only by the logical storage
backend, and represents the volume group name. For convenience and
back-compatibility, <source> <name> defaults to the pool name if not
specified when the pool is defined, and <pool> <name> defaults to the
source name if not specified. There is no requirement that pool and
source name be the same, though.
While admittedly it seems a little weird, it does allow more
flexibility (pool name not tied to vol group name), and allows <source>
to fully specify a logical pool source, as it does for the other pool
types[*]. Defaulting the source name from the pool name means all
existing pool XML definitions continue to work. Defaulting the pool
name from the source name is simply a matter of convenience (but perhaps
a step too far?)
If this is accepted, logical pool discovery can then return a bunch of
sources like:
<source><name>VolGroup00</name></source>
<source><name>VolGroup01</name></source>
Please note I'll be on vacation next week (Aug 11-15), so I may not be
responding until the following week.
Thanks,
Dave
[*] Well ... almost. Note that directory pools have a similar issue --
the "source" of the pool is given by the <target> <path> -- there's no
<source>. I suppose implementing directory pool discovery (for the sake
of completeness) means addressing this as well, maybe via some similar
mechanism ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: storage-source-name.patch
Type: text/x-patch
Size: 5201 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20080808/ace360a8/attachment-0001.bin>
More information about the libvir-list
mailing list