Bug 1655911 - guest pinned to hostA is show as up on both host after migration to hostB
Summary: guest pinned to hostA is show as up on both host after migration to hostB
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.7
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.3.3
: 4.3.0
Assignee: Sharon Gratch
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-04 09:06 UTC by Marian Jankular
Modified: 2020-08-03 15:35 UTC (History)
8 users (show)

Fixed In Version: ovirt-engine-4.3.2
Doc Type: Bug Fix
Doc Text:
In this release, the following changes have been made in the view filters for VMs in the Administration Portal under Compute > Hosts > selected host: New view filter names: - From “Running on host” to “Running on current host” (default view) - From “Pinned to host” to “Pinned to current host” - From “All” to “Both” - when “Both” is selected, a new column named “Attachment to current host” is displayed to indicate that the VM is: “Running on current host” , “Pinned to current host”, or “Pinned and Running on current host”.
Clone Of:
Environment:
Last Closed: 2019-05-08 12:39:01 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)
screenshots + virsh output (285.11 KB, application/x-xz)
2018-12-04 09:06 UTC, Marian Jankular
no flags Details
running+pinned (265.89 KB, application/x-xz)
2018-12-06 11:53 UTC, Marian Jankular
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1085 0 None None None 2019-05-08 12:39:14 UTC
oVirt gerrit 97206 0 master MERGED webadmin: Re-arrange the views of host->Virtual Machine's sub tab 2020-04-30 12:28:38 UTC

Description Marian Jankular 2018-12-04 09:06:41 UTC
Created attachment 1511234 [details]
screenshots + virsh output

Description of problem:
guest pinned to hostA is show as up on both host after migration to hostB

Version-Release number of selected component (if applicable):
rhvm-4.2.7.5-0.1.el7ev.noarch
ovirt-web-ui-1.4.4-2.el7ev.noarch

How reproducible:
always

Steps to Reproduce:
1. pin vm to hostA
2. migrate vm to hostB
3. check vms under host virtual machines tab

Actual results:
vm is visible on both host

Expected results:
vm will be visible only on hosts that is hosting the vm

Additional info:
vm is not running on both host, this is only display issue

Comment 1 Michal Skrivanek 2018-12-05 06:43:59 UTC
Both host images are of the same host?

Comment 2 Marian Jankular 2018-12-05 11:32:01 UTC
image dell-r430-01.png is from host dell-r430-01 and image dell-r430-03.png is from host dell-r430-03

Comment 3 Michal Skrivanek 2018-12-05 13:46:56 UTC
right, i mixed up the files. Looks like related to that pinning - Sharon? We probably need to change the way we filter VMs when they are running on different host than it's pinned to

Comment 4 Sharon Gratch 2018-12-05 14:24:08 UTC
(In reply to Michal Skrivanek from comment #3)
> right, i mixed up the files. Looks like related to that pinning - Sharon? We
> probably need to change the way we filter VMs when they are running on
> different host than it's pinned to

According to attached screenshots, both views for host->'virtual machines' sub tab are shown with "VMs" filter set to "All" (there is "VMs:" filter in upper part of the screen with 3 options: "All", "Running on host", "Pinned to host"). Since the VM is running on one host and pinned/assigned to the other then it is shown on both views. So I'm not sure it is a bug.

Comment 5 Sharon Gratch 2018-12-05 14:24:54 UTC
Marian, can you please check what is displayed for both hosts under "running on hosts" and "pinned to host" filters?

Comment 6 Marian Jankular 2018-12-06 11:53:26 UTC
Created attachment 1512061 [details]
running+pinned

hi, 
attaching requested screenshots, i have already deleted previous vm due to lack of space on our SD, so this time vm name is mjankula-dns2.
looking at "running on host" vm is only showed on host that is running on, I would say the "all" tab is maybe useless there and is only causing misunderstandings, what do you think?

Comment 7 Sharon Gratch 2018-12-06 13:56:42 UTC
(In reply to Marian Jankular from comment #6)
> Created attachment 1512061 [details]
> running+pinned
> 
> hi, 
> attaching requested screenshots, i have already deleted previous vm due to
> lack of space on our SD, so this time vm name is mjankula-dns2.
> looking at "running on host" vm is only showed on host that is running on, I
> would say the "all" tab is maybe useless there and is only causing
> misunderstandings, what do you think?

Hi,
I think that there is a value for showing this "All" tab of all VMS related/influenced by a host.
Filtering all VMS currently running on the host is one thing but filtering all VMS pinned/assigned to the host is also important since it shows all VMS that will start running on that host after running/restart (even if they are not running on the host now).

Now, if a user plans putting this host to maintenance for upgrading or if the host is in non-operational state then I guess the user would like to see which vms will be influenced by that.

the only suggestion I have is to switch the filter tabs order to:
"Running on host", "Pinned to host", "All/Both" 
so that the "All" won't be the default.

What do you think?

Comment 8 Marian Jankular 2018-12-06 14:52:26 UTC
reply from customer:

"IT is not only the All Tab, but even the count of the VMs running on each host is wrong, it counts the unavailable VM in this case."

Comment 9 Michal Skrivanek 2018-12-10 15:56:38 UTC
what is a "unavailable VM"?

Comment 10 Marian Jankular 2019-01-01 15:58:57 UTC
it means that vm count on the host is taken from "all tab" instead of "running on host tab"
Or in other words:

Situation before migration
HostA - vmcount - 10 (including vmA that is pinned to this host)
hostB - vmcount - 10 

you migrate vmA to hostB

Situation after migration
HostA - vmcount - 10 
hostB - vmcount - 11

Comment 11 Sharon Gratch 2019-01-08 17:04:18 UTC
(In reply to Marian Jankular from comment #10)
> it means that vm count on the host is taken from "all tab" instead of
> "running on host tab"
> Or in other words:
> 
> Situation before migration
> HostA - vmcount - 10 (including vmA that is pinned to this host)
> hostB - vmcount - 10 
> 
> you migrate vmA to hostB
> 
> Situation after migration
> HostA - vmcount - 10 
> hostB - vmcount - 11

I guess you are referring to the number of lines (=vms) displayed with the "All" tab. So this is a correct behaviour for that tab since it is reflecting the query result and since with "All" tab filter then all vms are displayed (pinned+running) then the result is that after migration: the number for hostA stays the same (since the migrated vm is still pinned to it) and the number for hostB is increased in one (since an additional VM is running on it).

When you check the "Running on host" tab then the number reflects what you want - only number of actual running vms is displayed.

It seems that the whole concept of "All" tab is confusing the user since he is interesting only on the "Running on host" tab.

Comment 12 Andreas Bleischwitz 2019-01-09 08:06:41 UTC
I just stumbled upon this "all" vs "running on this host" topic at a customer where I had to assist with some clean-up.
Not realizing the inclusion of pinned vms in the default view, the presence of one vm on two hosts in that default view raised my blood pressure.

I don't think that it's a good idea to have pinned hosts shown up as regular vms in that view. As an administrator I would not be able to identify them as pinned vms at a first glance and may take steps to solve a "one vm running on two hosts" scenario. There should be some kind of overlay icon attached to the vm-status field.

I'm note voting against a inclusion of pinned vms into this view - just that they should be marked as such.

Just my 2¢

Comment 13 Sharon Gratch 2019-01-09 12:17:54 UTC
(In reply to Andreas Bleischwitz from comment #12)
> I just stumbled upon this "all" vs "running on this host" topic at a
> customer where I had to assist with some clean-up.
> Not realizing the inclusion of pinned vms in the default view, the presence
> of one vm on two hosts in that default view raised my blood pressure.
> 
> I don't think that it's a good idea to have pinned hosts shown up as regular
> vms in that view. As an administrator I would not be able to identify them
> as pinned vms at a first glance and may take steps to solve a "one vm
> running on two hosts" scenario. There should be some kind of overlay icon
> attached to the vm-status field.
> 
> I'm note voting against a inclusion of pinned vms into this view - just that
> they should be marked as such.
> 
> Just my 2¢

Hi Andreas,

Thanks for this clarification.
So the changes we are suggesting for solving that are: 
1) Make the "Running on host" tab as the default first tab instead of the confusing/less used "All" tab. 
2) In the "All" tab view - mark each VM as "running on host", "pinned to host" or "both", so it will be easy to identify the VM's status.

Comment 14 Ryan Barry 2019-01-21 14:53:31 UTC
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Comment 16 RHV bug bot 2019-02-21 17:26:22 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 17 Polina 2019-02-25 11:59:01 UTC
Verified on ovirt-engine-4.3.1.2-0.0.master.20190220155021.git90ab3d9.el7.noarch
Run VMs with different pinning. The views are correct according to the described doc text.

the scenario to check the views:

vm            - pinned host  - run on host

vm0 (desktop) - pinned 1     -  run on 1
vm1 (HP)      - pinned 1 2   -  run on 2
vm2 (server)  - pinned 1 2 3 -  run on 3

pool1         - pinned to 2 - run on 1
pool2         - pinned to 2 - run on 2
pool3         - pinned to 2 - don't run

----------------------------------------
migrate 

vm0 -> host2
vm1 -> host3
vm2 -> host1
pool1 -> host3

Comment 18 RHV bug bot 2019-03-05 21:22:45 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 24 Polina 2019-03-19 14:13:47 UTC
verified on Downstream build ovirt-engine-4.3.2.1-0.1.el7.noarch according to the https://bugzilla.redhat.com/show_bug.cgi?id=1655911#c17.

Comment 26 errata-xmlrpc 2019-05-08 12:39:01 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/RHEA-2019:1085

Comment 27 Daniel Gur 2019-08-28 13:13:32 UTC
sync2jira

Comment 28 Daniel Gur 2019-08-28 13:17:46 UTC
sync2jira


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