[virt-tools-list] Re: [fedora-virt] ANNOUNCE: New release virt-manager 0.8.0

[Cole Robinson]

(cc-ing Jeremy Perry, the usability dude working on virt-manager)

On 07/29/2009 06:21 AM, Ján ONDREJ (SAL) wrote:
> Hello,
> 
>   new virt-manager looks nice and is working well for me, but I have some
> comments:
>

Thanks a lot for the very quick feedback! This is all useful stuff.

A big part of the manager UI rework was to optimize for the 'desktop
virtualization' case, where the user only has 1 connection (the local
machine). Ideally in this case, the user shouldn't have to know what HV
or connection they are on, virt-manager should just start up and show
their VMs (we aren't fully there yet, but it's the end goal).

That said, we still need to enable the 'multi host, many VMs' management
case. I admit that this release did regress the usefulness of the UI for
that case a bit, but we will resolve this in future releases.

> - gray color for "Not Connected" hosts looks a bit cold. I have aprox 10
>   hosts configured and whole screen is cold. May be it will be nicer to
>   add an image, like for running/stopped guest and also ability to
>   connect/disconned by clicking on this image.
> 

I know what you mean, having a sea of many connections all colored in
gray is a bit much. We may try using the manager view only for 'Active'
connections, and hiding the rest behind a menubar menu. There are a
couple ideas floating around that we need to play with, keep an eye on
virt-tools-list for future RFCs

> - host CPU usage is missing. In older virt-manager there was also CPU usage
>   graphs on main screen for host, not only for guests
> 

This was intentional. Going forward, we want to have a separate screen
for more thorough listing of host and guest stats, since the manager
view will never be sufficient in this case. We dropped the graph from
the connection row to keep it as small as possible.

> - guest CPU usage box is too high, if I have multiple hosts and guests,
>   they need to be on multiple pages due to hight of this box.
> 

This can probably be shrunk a bit, yes. Eventually we want to have OS
icons for VMs in the manager view though, which will pop the size back
up. Maybe it's worth having a 'compact' view option that keeps things
nice and small, for the user managing many VMs + hosts. Should be pretty
easy to implement as well.

> - when tryed to force poweroff guest with older libvirt, guest was stopped,
>   but python exception was raised. After update of libvirt from virt-preview
>   repository this message disappeared.
> 

Hmm, not sure about this. If you reproduce with the new libvirt, please
post the backtrace.

> - only one graph can be displayed. I have to choose, if I need network,
>   disk or CPU graph and only one can be displayed. With older version
>   there was multiple graphs available.
> 

See comments above: we want to keep the manager view simple and small,
the proper way forward for this is a 'stats' screen.

> - in virt-manager icon on panel, can you please sort hosts in same order
>   like in main window and may be hide "not connected" hosts (virt-manager
>   icon can't do anything with non-connected hosts).

Yes, good idea.

> 
> And one thing, which can make me happy. When I am trying virtual machines, I
> often reinstall existing one. Then I need to boot from network and after
> installation again from disk. I can't test new gPXE until it will work with
> my F11 kernel, may be it's better with this, but with currently functional
> bootrom I can't boot from disk if network boot is enabled and vice versa.
> If my guest is set to boot from disk (after previous installation)
> and I need to reinstall it, I have to do these steps:
> 
>   - click details panel (i)
>   - click "Boot Options"
>   - click on "Boot Device" menu
>   - select "Network (PXE)" and confirm (click)
>   - click "Apply"
>   - click back to guest console
>   - click start (play button)
> 
> If my guest was running and I have to force it off, these additional steps
> are required:
> 
>   - click on "v" button right of poweroff button
>   - click force off
>   - click "Yes"
> 
> Can this process be a bit simplified, 7-10 steps are too many.
> When testing development/rawhide systems, I have to repeat these steps
> multiple times. Do we really need this "Apply" button. I looked a bit to
> virt-manager sources and may be apply code can be called after boot device
> was changed.
> 

Someone actually just filed a bug about the 'apply' button issue. I'm
hesitant to change it because it would make the 'boot device' screen
have different behavior from the rest.

If the qemu boot menu option worked, it would simplify the process,
though virt-manager may need to help the situation by specifying a boot
order, rather than a single boot device.

The destroy confirmation also needs a "Don't show this again" option, so
users can opt out. We can probably do this per VM, and also add a global
option to disable it.

> These are only suggestions for improvements. You can ignore them, if you
> consider it non useful. :-)
>

No way! This stuff is very useful.

Thanks,
Cole