[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