Project

General

Profile

Actions

Bug #8131

closed

The virt-who registers host systems to incorrect organization

Added by Thomas McKay over 9 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Difficulty:
medium
Triaged:
Yes
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1155236
++ This bug was initially created as a clone of Bug #1051020 ++

Description of problem:

Running virt-who on virtual machine running on RHEV/VMware environment registers hosts to wrong organization, it does not registers host to the same organization in which virtual system has been registered.

Version-Release number of selected component (if applicable):

virt-who-0.8-9.el6.noarch

How reproducible:

I think this is only happening when hosts were previously registered to SAM. So on registration virt-who registers them to same organization not to the one in which virtual machine has been registered.

Steps to Reproduce:
1. Create multiple organizations on SAM 1.3
2. Register virtual machine to one organization(say A)
3. Run virt-who on virtual machine and check if hosts are appearing in same organization
4. If hosts are appearing in correct organization then delete virtual system and host from WebUI and using headpin command as below,

Below command is only required for host machines,

  1. headpin -u admin -p admin system remove_deletion --uuid=uuid-of-host

5. Register virtual machine to another organization(say B) and rerun virt-who on that.

Actual results:

Host systems are getting registered to wrong organization.

Expected results:

Host systems should be registered to same organization in which virtual machine has been registered.

--- Additional comment from Amit Upadhye on 2014-01-09 09:59:24 EST ---

Additional Information:

Internal GSS reproducer:

Virtual Machine: 10.65.211.70 root/redhat23
SAM: https://vm27.gsslab.pnq.redhat.com/sam admin/admin root/redhat

Virtual Machine is registered to organization aupadhye and all hosts are registered to organization amitu.

--- Additional comment from Amit Upadhye on 2014-01-09 10:00:37 EST ---

The virt-who is configured with correct organization details:

  1. Options for RHEV-M mode
    VIRTWHO_RHEVM_OWNER=aupadhye
    VIRTWHO_RHEVM_ENV=Library
    VIRTWHO_RHEVM_SERVER=https://lab-rhevm.gsslab.pnq.redhat.com:8443
    VIRTWHO_RHEVM_USERNAME=
    VIRTWHO_RHEVM_PASSWORD=RedHat1!

--- Additional comment from Radek Novacek on 2014-01-10 03:58:13 EST ---

virt-who only report host/guest association using the data (owner/env) from the config file. It doesn't do any registration by itself. Are you sure that this is bug in virt-who? It seems more like bug in SAM to me.

Do you supply correct VIRTWHO_RHEVM_OWNER in the virt-who config file after the change?

--- Additional comment from Amit Upadhye on 2014-01-18 06:15:43 EST ---

(In reply to Radek Novacek from comment #3)

virt-who only report host/guest association using the data (owner/env) from
the config file. It doesn't do any registration by itself. Are you sure that
this is bug in virt-who? It seems more like bug in SAM to me.

Do you supply correct VIRTWHO_RHEVM_OWNER in the virt-who config file after
the change?

Yes, virt who is configured with correct organization details. Have you checked reproducer mentioned in comment 1 ?

--- Additional comment from Amit Upadhye on 2014-04-11 17:09:00 EDT ---

Hello,

Is there any status update on this one ?

Thank you,
Amit Upadhye.

--- Additional comment from Radek Novacek on 2014-04-14 08:46:50 EDT ---

I don't think it's bug in virt-who, as virt-who doesn't do any registration by itself.

Reassigning to SAM for now.

--- Additional comment from Carter Kozak on 2014-05-29 10:53:53 EDT ---

This is definitely a candlepin issue, however I believe it has been fixed (or throws a better error).

Hypervisor checkin reports a map of hypervisor ids -> list of guest ids
Ex: {hypervisor1: [guest1, guest2, guest3]}

Hypervisor ids used to be globally namespaced, so if there was a consumer that existed with hypervisor id "hypervisor1" in a different org, it would be updated with guest1,2, and 3 (pretty bad bug). We've fixed this in recent versions, but I can't tell what sam this customer is using. Do you have any idea?

--- Additional comment from Amit Upadhye on 2014-06-10 12:35:27 EDT ---

(In reply to Carter Kozak from comment #7)

This is definitely a candlepin issue, however I believe it has been fixed
(or throws a better error).

Hypervisor checkin reports a map of hypervisor ids -> list of guest ids
Ex: {hypervisor1: [guest1, guest2, guest3]}

Hypervisor ids used to be globally namespaced, so if there was a consumer
that existed with hypervisor id "hypervisor1" in a different org, it would
be updated with guest1,2, and 3 (pretty bad bug). We've fixed this in
recent versions, but I can't tell what sam this customer is using. Do you
have any idea?

Customer is using SAM 1.3 and I also confirmed this behaviour on 1.3 version

--- Additional comment from mithun kalyat on 2014-07-29 09:44:05 EDT ---

Hello,

I have one case with customer reporting similar issue. Virt-who create host on incorrect organization of SAM server. Problem with SAM server (rhel6.5) and virt-who (rhel6.5).

Regards,
Mithun Kalyat.

--- Additional comment from Carter Kozak on 2014-07-29 09:46:09 EDT ---

Virt-who will always register the host to the same organization that the virt-who instance is registered to, it does not have any concept of what org the guest is in.

--- Additional comment from Amit Upadhye on 2014-08-20 08:10:30 EDT ---

(In reply to Carter Kozak from comment #10)

Virt-who will always register the host to the same organization that the
virt-who instance is registered to, it does not have any concept of what org
the guest is in.

Hello,

This is still reproducible on SAM 1.4,

Reproducer details,

Virtual system: dhcp233-29.gsslab.pnq.redhat.com(root/redrhn)
SAM: vm203.gsslab.pnq.redhat.com(root/harekrishna23 admin/admin)

The virt-who configuration on client dhcp233-29.gsslab.pnq.redhat.com:

  1. cat /etc/sysconfig/virt-who
  2. Register guests using RHEV-M
    VIRTWHO_RHEVM=1
  3. Options for RHEV-M mode
    VIRTWHO_RHEVM_OWNER=aupadhye-org
    VIRTWHO_RHEVM_ENV=Library
    VIRTWHO_RHEVM_SERVER=https://lab-rhevm.gsslab.pnq.redhat.com:443
    VIRTWHO_RHEVM_USERNAME=
    VIRTWHO_RHEVM_PASSWORD=RedHat1!

virt-who logs for specifically host 45b0c690-33da-408a-b719-2dc077f18be0,

2014-08-20 22:47:29,830 [DEBUG] @subscriptionmanager.py:89 - Sending update in hosts-to-guests mapping: {'45b0c690-33da-408a-b719-2dc077f18be0': ['28f6e74c-a194-4dc2-84cd-5d7b5911ef7b', '1c55fd22-eff6-43fb-ba69-8710608a5539', '1b2ece41-c73e-43fc-9322-8a170acd0d6b', '178d2407-1f06-47d9-b0bf-d12553d135c6', '2cedf24e-7c66-42fd-a6b6-b8602c181d2e']

The candlepin logs on SAM shows that system 45b0c690-33da-408a-b719-2dc077f18be0 is in aupadhye-org,

2014-08-20 17:21:37,995 [req=e8daa763-756b-4dad-b946-131d8df49fe1, org=aupadhye-org] INFO org.candlepin.resource.HypervisorResource - Checking virt host: 45b0c690-33da-408a-b719-2dc077f18be0

but on WebUI it is actually registered to another mkalyat organization, I have attached the screen-shot wrong-org.png which shows system registered to mkalyat instead of aupadhye-org. Another screen-show aupadhye-org.png shows there is only one virtual system registered.

--- Additional comment from Amit Upadhye on 2014-08-20 08:11:31 EDT ---

--- Additional comment from Amit Upadhye on 2014-08-20 08:12:32 EDT ---


Related issues 1 (0 open1 closed)

Related to Katello - Tracker #8059: Virtualization host-to-guestRejectedThomas McKay

Actions
Actions #1

Updated by Thomas McKay over 9 years ago

Actions #2

Updated by Thomas McKay over 9 years ago

  • Status changed from New to Assigned
Actions #3

Updated by The Foreman Bot over 9 years ago

  • Status changed from Assigned to Ready For Testing
  • Target version set to 59
  • Pull request https://github.com/Katello/katello/pull/4779 added
  • Pull request deleted ()
Actions #4

Updated by Thomas McKay over 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #5

Updated by Eric Helms over 9 years ago

  • translation missing: en.field_release set to 14
  • Difficulty set to medium
  • Triaged changed from No to Yes
Actions

Also available in: Atom PDF