Bug 1413270 - Mapping of VMs with multiple VCenters or lots of hypervisors does not scale
Summary: Mapping of VMs with multiple VCenters or lots of hypervisors does not scale
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscriptions - virt-who
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: Unspecified
Assignee: Barnaby Court
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-14 09:00 UTC by Kenny Tordeurs
Modified: 2020-12-14 08:01 UTC (History)
7 users (show)

Fixed In Version: virt-who-0.20.2-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-14 20:40:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kenny Tordeurs 2017-01-14 09:00:38 UTC
Description of problem:
When having multiple VCenters only 1 VCenter mapping/config is sent per minute.

The info about a new host comes from the VCenters to virt-who in a timely manner but virt-who only passes on hosts-to-guests mappings to Satellite for one VCenter at a time, and even waits a minute before sending the next VCenter.

Here is a list of tasks, you can see that because of the extra 60 seconds wait time per task the mapping might take several minutes:

Action                      State     Result     Started at                 Ended at                    User
=========================================================================================================================
Hypervisors                 stopped   success   2017-01-06 15:34:52 +0100   2017-01-06 15:37:42 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 15:30:57 +0100   2017-01-06 15:33:47 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 15:20:20 +0100   2017-01-06 15:24:26 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 15:15:12 +0100   2017-01-06 15:19:13 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 15:05:53 +0100   2017-01-06 15:10:03 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 15:00:38 +0100   2017-01-06 15:04:46 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:55:18 +0100   2017-01-06 14:59:31 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:50:02 +0100   2017-01-06 14:54:11 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:44:22 +0100   2017-01-06 14:48:54 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:37:17 +0100   2017-01-06 14:41:33 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:31:54 +0100   2017-01-06 14:36:08 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:25:09 +0100   2017-01-06 14:29:18 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:19:53 +0100   2017-01-06 14:24:03 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:14:16 +0100   2017-01-06 14:18:47 +0100   foreman_api_admin
Hypervisors                 stopped   success   2017-01-06 14:08:49 +0100   2017-01-06 14:13:09 +0100   foreman_api_admin
=========================================================================================================================

Version-Release number of selected component (if applicable):
virt-who-0.17-10.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Setup multiple VCenters with lots of hypervisors
Sending update in hosts-to-guests mapping for config "vcenter1": 88 hypervisors and 1603 guests found
Sending update in hosts-to-guests mapping for config "vcenter2": 34 hypervisors and 357 guests found

2. Lots of actions happening on the VCenters
3. Deploy new VM on VCenter

Actual results:
VM is not able to pick up its derived SKU because mapping is not yet completed.

Expected results:
VM to pick up its derived SKU

Additional info:

Workaround:
~~~
If the mapping has not completed within the time frame of the provisioned machine you could use the temporary subscription until the mapping has completed.
This process is described here https://access.redhat.com/documentation/en/red-hat-satellite/6.2/single/virtual-instances-guide/#temporary_subscriptions
~~~

Comment 3 Kevin Howell 2017-06-26 14:50:19 UTC
virt-who-0.19-3 and candlepin-2.0.36-1 should fix this. Changes were made to how virt-who reports data (w/ the work done for bug 1436811).

Comment 4 Mihir Lele 2017-07-17 19:32:54 UTC
Hello,

Candlepin-2x version will not be made available until 6.3. Is it possible to backport it to 6.2.x?

Comment 5 Kevin Howell 2017-07-20 14:30:52 UTC
It should be sufficient to distribute newer virt-who version with the virt-who fixes, so we will plan to package and ship newer virt-who with Sat 6.2.x.


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