I'm handling with an oVirt bug, about a race condition during parallel
registering hosts:

The vds_spm_id from vds_spm_map table is filled with a code
select/increment/insert. Registering many hosts at same time
causes a race condition. More than one java thread comes
up with the same value for selectedId, since that's just being
derived from knowledge about the set of vds_spm_id_map entries
already in the database.
This patch change the way to obtain the vds_spm_id to be
through a database sequence.

The reviewer wrote:
"... Each pool can have max vds_spm_id equals to 255. So, by using
sequence count the problem of parallel registration will be solved,
but a number of vdsms at pool will be reduced. ..."

Mailing him for details, he added:
"a limitation is coming from side of vdsm, if I am correct it is because
of using SAN lock, so they just can not accept spm id which is higher
than 255."

Trying to reproduce the vdsm limitation, no problem was found:

engine=# select * from vds_spm_id_map;
           storage_pool_id            | vds_spm_id |
 e32f1e2a-b5bb-11e1-9431-52540038c4e1 |        259 |

My host added with vds_spm_id = 259 is fully functional, with some
storage pools attached and so forth.
Since I'm not able to reproduce, I'd like to ask you guys if someone
could point me to the right direction to reproducing - or clarify
where is the mentioned limit.

vdsm-devel mailing list

Reply via email to