Bug 1127965

Summary: [RFE] Please add libvirt parameter for using Red Hat Enterprise Linux for Virtual Datacenter in kvm environments.
Product: Red Hat Enterprise Linux 7 Reporter: Yoshinori Takahashi <hkim>
Component: virt-whoAssignee: Radek Novacek <rnovacek>
Status: CLOSED ERRATA QA Contact: Li Bin Liu <liliu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: gxing, ovasik, shihliu
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-who-0.11-3.el7 Doc Type: Enhancement
Doc Text:
Feature: Add ability to read list of guests from remote libvirt hypervisor. Reason: virt-who should be able to report host/guest association to the Subscription Asset Manager and/or Satellite. Result: virt-who now supports reading list of guests from remote libvirt daemon.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 10:23:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 2 Radek Novacek 2014-08-08 05:55:28 UTC
Do I understand it correctly that the customer wants _remote_ connection to libvirt to be supported in virt-who?

Comment 4 Radek Novacek 2014-10-01 13:14:46 UTC
Support for remote libvirt connections has been added to upstream repository:

https://git.fedorahosted.org/cgit/virt-who.git/commit/?id=bfc6385a0052eb5425951de21f894a3771032332

Comment 5 Radek Novacek 2014-10-14 12:17:46 UTC
This feature is present in the latest build: virt-who-0.11-2.el7.

Comment 7 Liushihui 2014-11-04 09:48:00 UTC
Check it on virt-who-0.11-2.el7. It still can't send the host/guest associate to SAM server when virt-who run at in remote libvirtd mode. Therefore, reopen it.

Version-Release number of selected component (if applicable):
subscription-manager-1.13.6-1.el7.x86_64
python-rhsm-1.13.6-1.el7.x86_64
virt-who-0.11-2.el7.noarch
katello-headpin-1.4.3.28-1.el6sam_splice.noarch
candlepin-0.9.6.5-1.el6sam.noarch

Reproduced process:
Make system has been registered to SAM server
1. Copy the ssh-key :
[root@hp-z220-06 ~]# ssh-keygen
[root@hp-z220-06 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub 10.66.100.110
2. Configure virt-who run at remote libvirtd mode
VIRTWHO_LIBVIRT_OWNER=lshtest
VIRTWHO_LIBVIRT_ENV=library
VIRTWHO_LIBVIRT_SERVER=qemu+ssh://10.66.100.110/system
VIRTWHO_LIBVIRT_USERNAME=root
VIRTWHO_LIBVIRT_PASSWORD=
3. Restart virt-who and check the log as the following
2014-11-04 17:44:44,423 [INFO]  @virtwho.py:457 - Using virt-who configuration: virt-who
2014-11-04 17:44:44,423 [DEBUG]  @virtwho.py:170 - Starting infinite loop with 5 seconds interval
2014-11-04 17:44:44,458 [DEBUG]  @libvirtd.py:89 - Starting libvirt monitoring event loop
2014-11-04 17:44:44,461 [INFO]  @libvirtd.py:177 - Using libvirt url: qemu+ssh://root.100.110/system?no_tty=1
2014-11-04 17:44:44,628 [DEBUG]  @libvirtd.py:202 - Virtual machine found: vm1: bf2cba1b-8fc2-484a-8255-5b17d0f8f935
2014-11-04 17:44:44,630 [DEBUG]  @libvirtd.py:202 - Virtual machine found: 7.0_Server_x86_64: e6a4da96-c8af-49cb-a85e-a5a5eb2bbc7b
2014-11-04 17:44:44,631 [DEBUG]  @libvirtd.py:202 - Virtual machine found: 6.4_Server_x86_64: b1617c51-2b6c-4f68-8630-74531d366c5a
2014-11-04 17:44:44,632 [DEBUG]  @libvirtd.py:202 - Virtual machine found: 6.5_Server_x86_64: b65033ea-97ef-4e02-bfbe-40dd8177b0fd
2014-11-04 17:44:44,634 [DEBUG]  @libvirtd.py:202 - Virtual machine found: 5.10_Server_x86_64: 46f1919e-be17-45bc-af40-ab5033a16891
2014-11-04 17:44:44,749 [INFO]  @subscriptionmanager.py:109 - Sending list of uuids: [{'guestId': '46f1919e-be17-45bc-af40-ab5033a16891', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': 'b1617c51-2b6c-4f68-8630-74531d366c5a', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': 'b65033ea-97ef-4e02-bfbe-40dd8177b0fd', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': 'bf2cba1b-8fc2-484a-8255-5b17d0f8f935', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': 'e6a4da96-c8af-49cb-a85e-a5a5eb2bbc7b', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}]

Actual results:
Virt-who doesn't send the host to SAM server, virt-who should use hypervisorCheckIn instead of sendVirtGuests in remote libvirtd mode

Comment 8 Radek Novacek 2014-11-05 11:55:24 UTC
Fixed in virt-who-0.11-3.el7.

Comment 10 Liushihui 2014-11-13 05:14:36 UTC
Verified it on virt-who-0.11-3.el7.

Version-Release number of selected component (if applicable):
subscription-manager-1.13.8-1.el7.x86_64
python-rhsm-1.13.7-1.el7.x86_64
virt-who-0.11-3.el7.noarch
katello-headpin-1.4.3.28-1.el6sam_splice.noarch
candlepin-0.9.6.5-1.el6sam.noarch

Verified process:
Make system has been registered to SAM server
1. Copy the ssh-key :
[root@hp-z220-06 ~]# ssh-keygen
[root@hp-z220-06 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub 10.66.100.110
2. Configure virt-who run at remote libvirtd mode
VIRTWHO_LIBVIRT_OWNER=lshtest
VIRTWHO_LIBVIRT_ENV=library
VIRTWHO_LIBVIRT_SERVER=qemu+ssh://10.66.100.110/system
VIRTWHO_LIBVIRT_USERNAME=root
VIRTWHO_LIBVIRT_PASSWORD=
3. Restart virt-who and check virt-who's log, it can send host/guest associate to SAM server successfully.
2014-11-13 11:31:23,555 [DEBUG]  @virtwho.py:83 - Using config named 'test-remote-libvirt'
2014-11-13 11:31:23,555 [INFO]  @virtwho.py:460 - Using configuration "test-remote-libvirt" ("libvirt" mode)
2014-11-13 11:31:23,555 [DEBUG]  @virtwho.py:170 - Starting infinite loop with 1 seconds interval
2014-11-13 11:31:23,591 [DEBUG]  @libvirtd.py:95 - Starting libvirt monitoring event loop
2014-11-13 11:31:23,594 [INFO]  @libvirtd.py:163 - Protocol is not specified in libvirt url, using qemu+ssh://
2014-11-13 11:31:23,594 [INFO]  @libvirtd.py:174 - Libvirt path is not specified in the url, using /system
2014-11-13 11:31:23,594 [INFO]  @libvirtd.py:187 - Using libvirt url: qemu+ssh://root.100.110/system?no_tty=1
2014-11-13 11:31:23,770 [DEBUG]  @libvirtd.py:216 - Virtual machine found: 6.5_Server_x86_64: eda58d15-b593-4467-b286-f1e107d90e83
2014-11-13 11:31:23,772 [DEBUG]  @libvirtd.py:222 - Virtual machine found: 5.10_Server_x86_64: c0cc4fc6-4d3d-4bf3-9fbb-4768e630b82c
2014-11-13 11:31:23,773 [DEBUG]  @libvirtd.py:222 - Virtual machine found: 6.5_Client_i386: 46f3c7a8-3c25-4908-a067-72f61dae0ca4
2014-11-13 11:31:23,774 [DEBUG]  @libvirtd.py:222 - Virtual machine found: 6.4_Server_x86_64: 4f762f0b-2dc2-450a-b4db-737216ffbbc6
2014-11-13 11:31:23,776 [DEBUG]  @libvirtd.py:222 - Virtual machine found: 7.0_Server_x86_64: cb470a2c-1005-4174-a5c7-2ba1cdbd190b
2014-11-13 11:31:23,807 [INFO]  @subscriptionmanager.py:116 - Sending update in hosts-to-guests mapping: {'003ac27c-ed28-e211-8973-10604b5b2b19': [{'guestId': 'eda58d15-b593-4467-b286-f1e107d90e83', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': 'c0cc4fc6-4d3d-4bf3-9fbb-4768e630b82c', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': '46f3c7a8-3c25-4908-a067-72f61dae0ca4', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': '4f762f0b-2dc2-450a-b4db-737216ffbbc6', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': 'cb470a2c-1005-4174-a5c7-2ba1cdbd190b', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}]}
2014-11-13 11:31:24,677 [INFO]  @virtwho.py:164 - Created host: 20e971de-6d38-4e16-a66f-f7a2adf3dcf3 with guests: [eda58d15-b593-4467-b286-f1e107d90e83, c0cc4fc6-4d3d-4bf3-9fbb-4768e630b82c, 46f3c7a8-3c25-4908-a067-72f61dae0ca4, 4f762f0b-2dc2-450a-b4db-737216ffbbc6, cb470a2c-1005-4174-a5c7-2ba1cdbd190b]

Comment 12 errata-xmlrpc 2015-03-05 10:23:20 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://rhn.redhat.com/errata/RHSA-2015-0430.html