Bug 1655911

Both host images are of the same host?

image dell-r430-01.png is from host dell-r430-01 and image dell-r430-03.png is from host dell-r430-03

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

(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.

Marian, can you please check what is displayed for both hosts under "running on hosts" and "pinned to host" filters?

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?

(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?

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."

what is a "unavailable VM"?

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

(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.

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¢

(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.

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

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

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

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

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.

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

sync2jira

sync2jira