Bug 1062745 - We need a prominent indication that oVirt is ready to start VMs
Summary: We need a prominent indication that oVirt is ready to start VMs
Keywords:
Status: CLOSED EOL
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: bugs@ovirt.org
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-07 21:32 UTC by Bob Doolittle
Modified: 2022-03-16 08:59 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-10-02 10:42:53 UTC
oVirt Team: Virt
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-45332 0 None None None 2022-03-16 08:59:05 UTC

Description Bob Doolittle 2014-02-07 21:32:31 UTC
Description of problem:

When oVirt is starting up, the VM tab or left frame do not give any indication whether or not the state of the system is ready to start VMs or not.

There should be some kind of indication. Perhaps the red triangles should be black or gray until a VM is available to be powered on (i.e. while no SPM has been established due to maintenance or activation).

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

How reproducible:
100%

Steps to Reproduce:
1. Put all Hosts into Maintenance
2. View VM tab

Actual results:
There is no indication that VMs cannot be started

Expected results:
Some different indication of state between:
- Powered off yet available to be started
- Not available to be started

Additional info:
This is most significant while hosts are coming out of maintenance and SPM is being established. If you are viewing the VM tab you will never know when the system is ready to start the VMs.

Comment 1 Itamar Heim 2014-02-09 08:53:02 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 2 Sandro Bonazzola 2014-03-04 09:27:29 UTC
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 3 Michal Skrivanek 2014-08-22 14:26:21 UTC
this bug won't fit into 3.5 release and is being deferred to a later release. If you deeply care about this bug and deserves to be re-evaluated please let me know

Comment 4 Bob Doolittle 2015-03-26 15:30:56 UTC
Another example of where the current UI falls down is when cloning a VM. The default Administrative Portal view of Virtual Machines gives no indication while the disk is locked during the clone operation. But the green run/play widget for the VM appears active.

IMO the run/play widget should not appear active if in fact the VM is not currently in a state where it can be run. This could be due to the Datacenter being down, a disk being locked, or presumably other factors.

Comment 5 Michal Skrivanek 2015-08-05 12:48:26 UTC
this low prio bug didn't make it for 3.6 beta cutoff, moving to 4.0

Comment 6 Sandro Bonazzola 2015-09-04 09:00:26 UTC
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Comment 7 Sandro Bonazzola 2015-10-02 10:42:53 UTC
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.


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