Bug 890022 - 3.2 - host-deploy: enforce random vdsm id when detecting duplication
3.2 - host-deploy: enforce random vdsm id when detecting duplication
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alon Bar-Lev
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2012-12-24 06:46 EST by Alon Bar-Lev
Modified: 2012-12-31 01:45 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-31 01:45:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 10338 None None None Never

  None (edit)
Description Alon Bar-Lev 2012-12-24 06:46:52 EST
Currently we fail installation if we detect a duplicate vdsm id reported by host. This was ever since 3.0.

With ovirt-host-deploy there is the option of enforcing vdsm id from engine, so we can detect this state and enforce random id.

The problem is that if I add two addresses of the *SAME* host, we think that the second addition is a duplicate vdsm id, and generate our own. As a result we have two hosts up and running at engine side, polling the same vdsm, while its unique id is the random enforced one (the first can be either random or real bios uuid).

Pros/Cons for that?
Comment 1 Alon Bar-Lev 2012-12-24 06:54:22 EST
This keep be ask, I thought that a proper discussion is in order, so I can refer to it.
Comment 2 Alon Bar-Lev 2012-12-24 06:54:56 EST
commit 47df0540d741bdc9380873309966d5c47fe665a1
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Mon Dec 24 11:45:23 2012 +0200

    host-deploy: enforce random vdsm id in case of duplicate
    Fail installation if a duplicate vdsm id is reported by vdsm.
    Manual intervention required:
     # uuidgen > /etc/vdsm/vdsm.id
    Enforce random vdsm id when duplicate is reported.
    A host can be added twice with different addresses/names, results in
    duplicate active hosts polling the same vdsm.
    Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=890022
    Change-Id: Id448585b502cd53510526bc0a09bd7f9cd22230b
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

Comment 3 Alon Bar-Lev 2012-12-24 07:25:38 EST
Test external tracker, should be nice but cannot add more than one in single commit?
Comment 4 Itamar Heim 2012-12-25 02:41:05 EST
you can have vdsm report the unique id in getVdsStats and verify it matches the engine's.
so once a host will change its unique id you can detect this and move the "old host" to maint or something like that.
if we are assuming vdsm will go down and up for such a change, using getVdsCaps will suffice, and no need to check it on each getVdsStats.
Comment 5 Alon Bar-Lev 2012-12-25 04:10:44 EST
Question: does it worth the effort, or better to leave implementation as-is.
Comment 6 Simon Grinberg 2012-12-25 11:42:49 EST
(In reply to comment #5)
> Question: does it worth the effort, or better to leave implementation as-is.

My initial thoughts where it's worth the effort, because when it happens it's just to confusing to figure out the problem. 

Don't forget duplicate IDs happen in some blade centers, meaning you have a bunch of identical hosts, not just two. A simple mistake may lead to adding the same host twice. 

On the other hand, if I understand correctly, this can't happen with RHEV-H hosts if RHEV-H registers to the manager.

So for it to happen:
1. Must be RHEL hosts 
2. Hosts must have same bios UUID 
3. Hosts must have more then one IP to begin with. 
If the 3 above is accurate then you may leave the current implementation as is.
Comment 7 Alon Bar-Lev 2012-12-25 14:48:14 EST
0. It can be RHEV-H.
3. Host can have single IP, but used as IP address, name, name.suffix, name.suffix.suffix.

I think Andrew did not want to handle this as it is less than 0.5%...

Note You need to log in before you can comment on or make changes to this bug.