From the logs, it doesn't look that virt-who is doing anything wrong.

When host1 is deleted, host 'cca20075-abb1-464a-80f1-3e8b6a07dc6c' disappears from the list of reported host/guest associations.

But after readding it, it got new uuid 'a0483d14-d738-4e60-8ede-62fe6bb70015' and virt-who reports that.

I don't see anything wrong with that (apart from changing the uuid, but that's coming from RHEVM, virt-who can't do anything about it).

Hi Radek
 
  Thanks for your explain. The problem is changing the uuid after readd the same host to rhevm.
  As Rhevm will regenerate a new uuid if readding the host which has been delete previously, Then virt-who will send the new uuid to the SAM server. However, if the old hypervisor hasn't been deleted by manual before add the new one, the old hypervisor will become a junk data in the SAM server. customers might be confused about it. In order to resolve this problem, I have two suggestions:
1. virt-who should determine whether both the new uuid and the old one which still exist on the SAM server are come from the host or not. if it's yes, replace the old one with the new one
2. rhevm should generate the same uuid to the same host. BTW, ESX hasn't this problem

Thanks.

(In reply to Radek Novacek from comment #2)
> From the logs, it doesn't look that virt-who is doing anything wrong.
> 
> When host1 is deleted, host 'cca20075-abb1-464a-80f1-3e8b6a07dc6c'
> disappears from the list of reported host/guest associations.
> 
> But after readding it, it got new uuid
> 'a0483d14-d738-4e60-8ede-62fe6bb70015' and virt-who reports that.
> 
> I don't see anything wrong with that (apart from changing the uuid, but
> that's coming from RHEVM, virt-who can't do anything about it).

virt-who can't possibly tell if the new uuid that appears is from the same host that disappeared earlier.

Reassigning to RHEV-M.

To clarify what is the issue here:

When a host is removed from hypervisor and then readded again, its ID changes. Would it be possible to preserve the ID? We need it to be the same for proper management of subscription in the SAM.

You can how is it used in the following file:
https://git.fedorahosted.org/cgit/virt-who.git/tree/rhevm.py

I think we just need to persist the UUID virt-who is suing.

Hi Shihui,
  Which RHEV-H build you used for this testing?
  1. checked your test version is virt-who-0.8-12.el7.
  2. checked your test steps with RHEL 6.5 as host.
  Can you please give more info here?

Thanks
Ying

Hi, Ying
   
  Please see it as the following reply

(In reply to Ying Cui from comment #7)
> Hi Shihui,
>   Which RHEV-H build you used for this testing?
===> I used  RHEL-6.5-20131213.0-Server-x86_64 as host
>   1. checked your test version is virt-who-0.8-12.el7.
===>I used virt-who-0.8-12.el7 on RHEL7 when I report this bug, it has the same problem if use virt-who-0.8-9.el6.noarch on RHEL6, I have confirmed with cshao
>   2. checked your test steps with RHEL 6.5 as host.
===>Please following test steps as the following:
1. Register system with virt-who to SAM server, Add three RHEL6.5 hosts to RHEVM
2. Configure virt-who run in the rhevm mode
VIRTWHO_DEBUG=1
VIRTWHO_INTERVAL=2
VIRTWHO_RHEVM=1
VIRTWHO_RHEVM_OWNER=ACME_Corporation
VIRTWHO_RHEVM_ENV=Library
VIRTWHO_RHEVM_SERVER=https://10.66.129.57:443
VIRTWHO_RHEVM_USERNAME=admin@internal
VIRTWHO_RHEVM_PASSWORD=redhat
3. Restart virt-who service ,make sure three hypervisors have been send to SAM server
#service virt-who restart
4. In the RHEVM web UI, delete host1 (the hypervisor hasn't been deleted on the SAM)
5. In the RHEVM web UI, add host1 to RHEVM again
6. Check the virt-who log in the /var/log/rhsm/rhsm.log
7. Check the SAM web UI

>   Can you please give more info here?
> 
> Thanks
> Ying

This problem occur on both RHEL and RHEV-H, not ovirt-node specific issue, need to move bug to another component to investigate.

Thanks
Ying

Moving this to virt-who, as this could also reproduced on RHEL, according to the last comment.

Fabian, Ying,

I'm not sure if I understand this correctly.

As I see it, the probem is that when host is removed and then readded to hypervisor, its UUID changes. Would it be possible to make this stable?

There is nothing virt-who can do about it, it just reads the host/guest associations from RHEV-M and reports it to subscription manager.

Hey radek,

yep you are right. We should keep the UUID.


Liushihui, can you tell me in what file the UUID is kept?

Here we go again.

My previous assumption was that the host (RHEV-H) side UUID was relevant.

But it seems that the UUID for the host-guest mapping is actually received from RHEV-M.

This can be seen here:
https://git.fedorahosted.org/cgit/virt-who.git/tree/virt/rhevm/rhevm.py
https://git.fedorahosted.org/cgit/virt-who.git/tree/virt/rhevm/rhevm.py#n66


Alon,
do you maybe know what UUID RHEV-M is using to identify a host?
Is the UUID taken from teh RHVE-H instance or is it internally maintained inside a db?

(In reply to Fabian Deutsch from comment #14)
> Here we go again.
> 
> My previous assumption was that the host (RHEV-H) side UUID was relevant.
> 
> But it seems that the UUID for the host-guest mapping is actually received
> from RHEV-M.
> 
> This can be seen here:
> https://git.fedorahosted.org/cgit/virt-who.git/tree/virt/rhevm/rhevm.py
> https://git.fedorahosted.org/cgit/virt-who.git/tree/virt/rhevm/rhevm.py#n66
> 
> 
> Alon,
> do you maybe know what UUID RHEV-M is using to identify a host?
> Is the UUID taken from teh RHVE-H instance or is it internally maintained
> inside a db?
Haven't got the foggiest - although I think you've got the wrong Alon.
Alon (BL) - does any of this sound familiar to you?

I do not see the host unique id reflected in the restapi, what you get is the host id within rhevm (engine unique id).

adding mskrivan for more information.

it should not be on node component as it will happen at generic host as well

That is what I wanted to find out in comment 14.
if we agree, then I see it more as a problem of RHEV-M.

But this is in general a conceptual question: Should the same host be identified as the same host in RHEV-M after it has been removed and re-added?

IMO the current solution (host get's new UUID when the host is added to RHEV-M) is a good the the right solution.

But then we need to see hwo this problem can be addressed.

Moving it to RHEV-M anyway.

reassigning - Host management is infra

I'm not sure though, that persisting the UUID on host is the way to go. When we remove the host in RHEVM it seems to me it should be removed from SAM too?

Remove and add is considered a new hypervisor deployment

When we remove the host in RHEVM , the hypervisor won't remove from SAM, it only can be removed by manual delete it in the SAM web UI. 

(In reply to Michal Skrivanek from comment #19)
> reassigning - Host management is infra
> 
> I'm not sure though, that persisting the UUID on host is the way to go. When
> we remove the host in RHEVM it seems to me it should be removed from SAM too?
> 
> Remove and add is considered a new hypervisor deployment

why won't virt-who save the FQDN of hosts, and then identify once a host that already exists is added? Why using the uuid?

Any other solution for that in the rhev-m side seems like a hack. Using the FQDN ensures it is the same host.

Any thoughts?

Only thing that virt-who report to the SAM is mapping between host and guest UUIDs.

Even if virt-who remembers that the new UUID has the same hostname as some old UUID it can't do anything about it. Reporting the old UUID would be wrong.

I'm not even sure we can get the FQDN from all the hypervisors virt-who can talk to (ESX, Hyper-V, ...).

(In reply to Radek Novacek from comment #22)
> Only thing that virt-who report to the SAM is mapping between host and guest
> UUIDs.
> 
> Even if virt-who remembers that the new UUID has the same hostname as some
> old UUID it can't do anything about it. Reporting the old UUID would be
> wrong.
> 
> I'm not even sure we can get the FQDN from all the hypervisors virt-who can
> talk to (ESX, Hyper-V, ...).

Can someone explain the flow of data here?

Is virt-who reporting the hosts from the rhev-m periodically?

If so, SAM can tell when a host that was reported in the past is no longer reported, and then assume it was removed, so the entitlement can be re-used.

Yes.virt-who reporting the hosts from the rhev-m periodically
Actually,  SAM can't remove any host automatically no matter it was still reporting or not. so it means the junk data can't be removed automatically. it only can be deleted manually.

Okay.
In that case I think we should go with exposing the host unique ID through the REST API, which will allow virt-who to use that one instead of the regular host ID.

Does that make sense?

Yes, I think so. Thanks.

(In reply to Liushihui from comment #26)
> Yes, I think so. Thanks.

After exploring this alternative I saw that the unique ID has some limitations, so it can't be relied on for this use-case.

The only way I see in solving this issue is to add support in removing hosts from SAM (and also query hosts) and then you'll be able to compare the hosts that the RHEV-M engine reports with the ones SAM reports, and remove "dead" hosts.

Moving back to virt-who for further examination.

virt-who can now optionally identify hypervisor using hostname or hardware uuid instead of uuid. It should fix the issue.

*** This bug has been marked as a duplicate of bug 1197970 ***