[libvirt] [PATCH 7/7] storage: Check for duplicate host for incoming pool def

[Peter Krempa]

On Mon, Apr 20, 2015 at 12:23:25 -0400, John Ferlan wrote:
> 
> 
> On 04/20/2015 11:11 AM, Ján Tomko wrote:
> > On Sun, Apr 19, 2015 at 08:49:12PM -0400, John Ferlan wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1171984
> >>
> >> Use the new virIsSameHostnameInfo API to determine whether the proposed
> >> storage pool definition matches the existing storage pool definition
> >>
> >> Signed-off-by: John Ferlan <jferlan at redhat.com>
> >> ---
> >>  src/conf/storage_conf.c | 11 ++++++++++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
> >> index 4852dfb..c1bc242 100644
> >> --- a/src/conf/storage_conf.c
> >> +++ b/src/conf/storage_conf.c
> >> @@ -2415,7 +2415,16 @@ virStoragePoolSourceMatchSingleHost(virStoragePoolSourcePtr poolsrc,
> >>      if (poolsrc->hosts[0].port != defsrc->hosts[0].port)
> >>          return false;
> >>  
> > 
> > This function is called when parsing the configuration, which should not
> > depend on host state.
> > 
> > For example, if libvirt is started really early at boot time and the
> > hostnames cannot be resolved by the DNS yet, they will pass the check
> > but they will disappear on libvirtd restart.
> 
> Hmm... the downside of unreliable dependencies.

Not only unreliable dependencies. The issue might also happen with
factors external to the host. For example by adding a new DNS name for
the "duplicate" host.

> 
> > 
> > The hostname->ip pairings are not stable either, so if we do this, I
> > think it should be done on pool startup, not config parsing.
> > 
> 
> Right, but by the time we get to pool startup we'd be at the same point
> as referenced above - if done early enough at boot time, then it's not
> going to fail, but perhaps better than nothing.

Well, that's actually not true. If the second (duplicate) pool is
starting at one point, the address either can be resolved and deemed
duplicate, or the resolution would fail anyways and the pool would not
be started.

When compared with the approach when defining the pool (or reading back
XML files):
1) if the hostname is not duplicate or not resolvable at the point when
you define the pool but changes to be duplicate later you wouldn't catch
the issue
2) if the pool source becomes duplicate in the life of the host it would
vanish after libvirt restart

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150421/1a828262/attachment-0001.sig>