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

Ján Tomko jtomko at redhat.com
Mon Apr 20 15:11:25 UTC 2015

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.

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.

> -    return STREQ(poolsrc->hosts[0].name, defsrc->hosts[0].name);
> +    if (STRNEQ(poolsrc->hosts[0].name, defsrc->hosts[0].name)) {
> +        /* Matching just a name isn't reliable as someone could provide
> +         * the name for one pool and the IP Address for another pool, so

Resolving them is IMHO just as unreliable.

Re: the original bug - is it possible to check that we have connected to
a session with a different hostname than what we requested?

Or just disallow starting two pools with the same targetname, since they
are supposed to be unique?

-------------- 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/20150420/6e17318e/attachment-0001.sig>

More information about the libvir-list mailing list