RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1416298 - Virt-who report wrong guests status for hyper-v when configure guests with same guest name
Summary: Virt-who report wrong guests status for hyper-v when configure guests with ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: alpha
: 7.7
Assignee: William Poteat
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-25 08:16 UTC by Liushihui
Modified: 2020-03-31 19:09 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-31 19:08:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
import_process1 (198.67 KB, image/jpeg)
2017-01-25 08:31 UTC, Liushihui
no flags Details
import_success (237.46 KB, image/jpeg)
2017-01-25 08:32 UTC, Liushihui
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:0990 0 None None None 2020-03-31 19:09:01 UTC

Description Liushihui 2017-01-25 08:16:48 UTC
Description of problem:
When export a vm then import it to hyperv, virt-who will report wrong guest's status to server.

Version-Release number of selected component (if applicable):
virt-who-0.17-10.el7sat.noarch
Satellite6.2.7-sp3
HYPERV2016

How reproducible:
Always

Steps to Reproduce:
1. In HyperV machine, create and start a VM(rhel69).

2. Configure virt-who run at hyperv mode to monitor the hyperv machine.
[root@bkr-hv03-guest20 virt-who.d]# cat /etc/virt-who.d/hyperv1 
[test-hyperv2]
type=hyperv
server=10.73.5.227
username=virtwho\administrator
encrypted_password=3ce98c643e783a83cc247b00ea3d2d3c
owner=org1
env=Library 
rhsm_username=admin
rhsm_encrypted_password=ce6d7d014da9d0a7f5590bdd15c376d2
rhsm_prefix=/rhsm
rhsm_port=443
rhsm_hostname=hp-ml370g6-01.rhts.eng.bos.redhat.com
hypervisor_id=hostname

3. Restar virt-who and check virt-who's log, virt-who can send correct guest's status to satellite
2017-01-25 02:41:56,268 [virtwho.main DEBUG] MainProcess(31205):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "virtwho_03": [
        {
            "guestId": "5EF3A910-F00F-7447-A995-2BE57CA30A6F", 
            "state": 1,          =======> It's correct to show guest is running 
            "attributes": {
                "active": 1,     =======> It's correct to show guest is running 
                "virtWhoType": "hyperv"
            }
        }
    ]
}
2017-01-25 02:41:58,211 [virtwho.main DEBUG] MainProcess(31205):MainThread @executor.py:send_report:101 - Report for config "test-hyperv2" sent

4. In HyperV machine, export the VM(rhel69).

5. In HyperV machine, import the VM(rhel69) which exported on step 4, in the "choose import type" window, choose "copy the virtual machine(create a new unique ID)", see screenshot import_process.jpeg.

6. After import VM successfully, please see screenshot import_succss.jpeg. check virt-who's log
[root@bkr-hv03-guest20 virt-who.d]#  tail -f /var/log/rhsm/rhsm.log
2017-01-25 02:52:02,500 [virtwho.main DEBUG] MainProcess(31205):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "virtwho_03": [
        {
            "guestId": "5EF3A910-F00F-7447-A995-2BE57CA30A6F", 
            "state": 5,              ====> It's wrong 
            "attributes": {
                "active": 0,          ====> It's wrong 
                "virtWhoType": "hyperv"
            }
        }, 
        {
            "guestId": "5EF3A910-F00F-7447-A995-2BE57CA30A6F", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "hyperv"
            }
        }
    ]
}
2017-01-25 02:52:05,375 [virtwho.main DEBUG] MainProcess(31205):MainThread @executor.py:send_report:101 - Report for config "test-hyperv2" sent


Actual results:
Virt-who can get the new imported VM, but the original guest's status is wrong.

Expected results:
As the original guest is running, it should show the original guest is running and the imported one is stop.
    "virtwho_03": [
        {
            "guestId": "5EF3A910-F00F-7447-A995-2BE57CA30A6F", 
            "state": 1,              ====> It should updated to "1" 
            "attributes": {
                "active": 1,          ====> It should updated to "1" 
                "virtWhoType": "hyperv"
            }
        }, 
        {
            "guestId": "5EF3A910-F00F-7447-A995-2BE57CA30A6F", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "hyperv"
            }
        }
    ]

Additional info:

Comment 1 Liushihui 2017-01-25 08:31:38 UTC
Created attachment 1244191 [details]
import_process1

Comment 2 Liushihui 2017-01-25 08:32:57 UTC
Created attachment 1244192 [details]
import_success

Comment 4 Kevin Howell 2017-06-26 14:34:24 UTC
Moving component to upstream virt-who (seems like a general virt-who issue).

Comment 6 William Poteat 2019-06-03 19:12:52 UTC
Why is this a valid test? It is not sustainable to create more than one guest vm with the same guest id. 
When you make the duplicate, change the system uuid and check the outcome.

Comment 8 William Poteat 2019-06-04 15:21:46 UTC
Can you give me the connection information to the hyperv manager so I can see what state is getting sent?

Comment 9 William Poteat 2019-06-04 15:59:37 UTC
The log also if you can capture it.

Comment 11 William Poteat 2019-06-05 12:57:04 UTC
Workaround: The state of the systems is stored in a hash table by "ElementName". That is the system name "7.6_Server_x86_64". It will only keep the state it gets last and use it for all systems with that name.
Rename the systems to be unique.

I will examine the collected data to see if there is a field that will always be unique for this purpose.

Comment 15 errata-xmlrpc 2020-03-31 19:08:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0990


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