Bug 970195

load column has been removed in 3.2...

(In reply to Itamar Heim from comment #2)
> load column has been removed in 3.2...

It has been replace by "Virtual Machines" column.

VMs are accounted in both source and destination hosts during the entire live migration.

For example, in a cluster with 4 VMs, if I request to live migrate all VMs (or just request the host where they run to enter Maintenance) the "Virtual Machines" column will show 4 VMs in each host totaling 8 VMs.

(In reply to Julio Entrena Perez from comment #3)
> (In reply to Itamar Heim from comment #2)
> > load column has been removed in 3.2...
> 
> It has been replace by "Virtual Machines" column.
> 
> VMs are accounted in both source and destination hosts during the entire
> live migration.
> 
> For example, in a cluster with 4 VMs, if I request to live migrate all VMs
> (or just request the host where they run to enter Maintenance) the "Virtual
> Machines" column will show 4 VMs in each host totaling 8 VMs.

I don't see an issue with each host showing 4 VMs during live migration - why is this incorrect?

(In reply to Itamar Heim from comment #4)
> I don't see an issue with each host showing 4 VMs during live migration -
> why is this incorrect?

Because "Hosts" tab will display a total of 8 VMs when only 4 VMs exist.

yes, during live migration there is a transient state in which both hosts carry the load of the VMs.
Andrew - thoughts?

I don't see transient double-counting of VMs as a problem. In a sense, there is a very brief period where the VMs do exist in two places at once. I'd prefer to overestimate load than underestimate it.

(In reply to James Rankin from comment #7)
> there is a very brief period where the VMs do exist in two places at once.
When 80+ 4-8GB VMs run in a host live migrating those is not a brief period at all: a single live migration can take 5+ minutes and they need to accomplish 80+.

> I'd prefer to overestimate load than underestimate it.
Customer expects an accurate report of the number of VMs in a host at any time, not an estimation.

(In reply to Julio Entrena Perez from comment #9)
> (In reply to James Rankin from comment #7)
> > there is a very brief period where the VMs do exist in two places at once.
> When 80+ 4-8GB VMs run in a host live migrating those is not a brief period
> at all: a single live migration can take 5+ minutes and they need to
> accomplish 80+.
> 
> > I'd prefer to overestimate load than underestimate it.
> Customer expects an accurate report of the number of VMs in a host at any
> time, not an estimation.

Julio, 
I see your point of getting an accurate number of VMs.

However, there's a real reasoning behind this presentation; During the migration
process (which indeed may take time), both source and destination servers are
allocating resources for the migrating VM. So in order to properly depict the
host status the VM should be counted, as it's consuming CPU, RAM and other resources.
Disregarding any of the hosts will leave 'black holes'. For example, think of
a destination server with no VMs, and one VM is migrating to it. If we do not
count that VM, we will see a server working hard (CPU, etc) with no VMs at all
which may open a lot of issues on this strange behavior.

May I ask which functionality the current state is disrupting? 
What is the query / action you're trying to do?

Created attachment 774172 [details]
Num. of VMs currently migrating

UX wise - I would like to keep the table grid clean as much as possible.
I suggest showing as proposed, the #vm that are migrated.
The tool tip will show the # of vms that migrate in and # vms that migrate out.

(look at the previous post for a screen capture)

(In reply to Eldan Hildesheim from comment #15)
> UX wise - I would like to keep the table grid clean as much as possible.
> I suggest showing as proposed, the #vm that are migrated.
> The tool tip will show the # of vms that migrate in and # vms that migrate
> out.
> 
> (look at the previous post for a screen capture)

Thanks Eldan, that's accurate indeed.
Does the total number of VMs include migrating in and/or migrating out VMs?

(In reply to Julio Entrena Perez from comment #16)
> 
> Thanks Eldan, that's accurate indeed.
> Does the total number of VMs include migrating in and/or migrating out VMs?

Julio, yes; the total includes migrating VMs.

(In reply to Doron Fediuck from comment #17)
> 
> Julio, yes; the total includes migrating VMs.

Thanks Doron.
Would it be possible to remove "migrating in" VMs from the total number of running VMs? Otherwise the problem would remain: we'd report more VMs than we have.

Summarizing the issue resolution;

1. Virtual Machines column contents will change to display the total VMs and in
brackets transitioning VMs. If no transitioning VMs, the brackets will not be displayed:

  24 (3)
  #VMs (# transitioning VMs).


2. Hovering above a specific row will show a tool-tip with an explanations:
"24 running VMs, out of which 3 are migrating".

Going forward to next version(s), we'll add a similar support to the API.

Created attachment 784269 [details]
screenshot showing initial state: 6 vms on one host, 0 on the 2nd

Created attachment 784271 [details]
screenshot showing start of migration: 6 vms on one host, 6 on the 2nd

Created attachment 784286 [details]
screenshot showing transition during migration: 6 vms on one host (6 in transition state), 4 on the 2nd (3 in transition state)

Andrew, please advice

*** Bug 1015182 has been marked as a duplicate of this bug. ***

This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

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.

http://rhn.redhat.com/errata/RHSA-2014-0038.html