Bug 1247926 - Guest's "active" status is 0 when suspend guest
Guest's "active" status is 0 when suspend guest
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Radek Novacek
Depends On:
  Show dependency treegraph
Reported: 2015-07-29 05:15 EDT by Liushihui
Modified: 2016-11-30 19:33 EST (History)
6 users (show)

See Also:
Fixed In Version: virt-who-0.14-4.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-19 06:57:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Liushihui 2015-07-29 05:15:29 EDT
Description of problem:
When suspend guest, check the guest's active status, it's ""active": 0"

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

How reproducible:

Steps to Reproduce:
1.Register system to satellite, start guest.
2.Configure virt-who run at kvm mode and restart virt-who service
3.Check virt-who's log
2015-07-27 10:35:06,150 [INFO]  @subscriptionmanager.py:136 - Sending domain info: [
        "guestId": "2c8198c2-8e26-4d70-89fb-9eaaf67aaf47", 
        "state": 1, 
        "attributes": {
            "active": 1, 
            "virtWhoType": "libvirt", 
            "hypervisorType": "QEMU"
4. Suspend guest, then check virt-who service

Actual results:
2015-07-27 10:35:06,150 [INFO]  @subscriptionmanager.py:136 - Sending domain info: [
        "guestId": "2c8198c2-8e26-4d70-89fb-9eaaf67aaf47", 
        "state": 3, 
        "attributes": {
            "active": 0, ====================================it should be "1"
            "virtWhoType": "libvirt", 
            "hypervisorType": "QEMU"

Expected results:
Guest's active status should be "1" after suspend it.

Additional info:
Comment 1 Radek Novacek 2015-08-04 09:03:24 EDT
Why do you think that the active status of suspended guest should be "1"?

There might be two points of view that can affect perception of this:

* I'm concerned about what's running on that VM (a service), in that case I consider only the state `RUNNING` as `active`. That's current virt-who behaviour

* I'm concerned about the system where is the VM running, meaning that the suspended machine is `active` because it consumes resources of given system (at least RAM).

Both of them are valid but I don't know to what group we should put virt-who. Do you know if this information is used anywhere?
Comment 2 Liushihui 2015-08-12 22:37:20 EDT
Radek, I'm sorry I haven't found doc about this function. and I agree with you that both of them are valid. However, I think it should be better to set active:1 when guest in suspend status. Since if we try to start guest when it in suspend status, it will remind info "error: Domain is already active". is that acceptable?

[root@ibm-x3250m4-03 ~]# virsh suspend 6.5_Server_x86_64
Domain 6.5_Server_x86_64 suspended

[root@ibm-x3250m4-03 ~]# virsh start 6.5_Server_x86_64
error: Domain is already active
Comment 3 Liushihui 2015-08-12 22:43:34 EDT
Actually,In RHEL5.11, it also show active:1 when guest is suspend
Comment 4 Radek Novacek 2015-08-18 11:56:27 EDT
Fixed in virt-who-0.14-4.el7.
Comment 6 Liushihui 2015-08-24 01:55:49 EDT
Verified it on virt-who-0.14-4.el7.noarch since guest show active:1 when guest is suspend.

Verified version

Verified process:
1.Register system to satellite, start guest.
2.Configure virt-who run at kvm mode and restart virt-who service
3.Suspend guest, then check virt-wh's log
        "guestId": "6641c133-ebfa-4ca7-8ddb-f9100a6b02fa", 
        "state": 3, 
        "attributes": {
            "active": 1, 
            "virtWhoType": "libvirt", 
            "hypervisorType": "QEMU"

Guest's active status is "1" after suspend it.
Comment 7 errata-xmlrpc 2015-11-19 06:57:37 EST
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.


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