Bug 734529 - Adding storage via file browser is inflexible and differs from 5.6 behaviour
Summary: Adding storage via file browser is inflexible and differs from 5.6 behaviour
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-30 17:20 UTC by James B. Byrne
Modified: 2012-06-20 12:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
No documentation needed
Clone Of:
Environment:
Last Closed: 2012-06-20 12:35:56 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0785 normal SHIPPED_LIVE virt-manager bug fix and enhancement update 2012-06-19 20:34:46 UTC

Description James B. Byrne 2011-08-30 17:20:23 UTC
Description of problem:

In virtual machine manager while adding a new virtual machine one is required to either accept the default directory and file name, or browse to an existing file name only.  There is no opportunity to browse to a directory and supply a file name.  Browsing to an empty directory results in the file browser never returning.

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


How reproducible:


Steps to Reproduce:
1.  create an empty directory
2.  create a new virtual machine
3.  select managed or other existing storage
4.  browse local to empty directory
  
Actual results:

Virtual machine manager file browser enters indefinite wait state with cursor displaying a spinning circle.

Expected results:

It should show the empty directory and allow direct input of a new file name to select that combination for the creation of the new virtual image storage.

Additional info:

This behaviour is very unintuitive and differs from that of 5.6 where one has the opportunity to browse to an empty directory and then provide the desired file name of the virtual storage. The VM manager will then create that file in that directory.  

Further, entering an indefinite wait state without providing any indication as to the cause of the problem is a defect.

As a work-around one may first manually create the desired file name in the desired location and then browse to that file.

Comment 2 Cole Robinson 2011-09-27 00:42:11 UTC
Thanks for the report, fixed upstream:

http://git.fedorahosted.org/git?p=virt-manager.git;a=commit;h=5a84a3a6276b367453f0b0315fa1d8569430cdc8

Comment 3 Cole Robinson 2011-09-27 18:42:48 UTC
FYI as a workaround you can type the full desired path into the text entry on the storage page of the create wizard.

Since this is urgent and kind of late for 6.2, moving to 6.3

Comment 5 Cole Robinson 2012-01-25 22:01:17 UTC
Moving to POST since it's upstream

Comment 6 Cole Robinson 2012-02-01 20:03:36 UTC
Fixed in virt-manager-0.9.0-8.el6

Comment 8 Daisy Wu 2012-02-13 06:21:03 UTC
This bug can be reproduced with:
kernel-2.6.32-220.el6.x86_64
libvirt-0.9.4-14.el6.x86_64
virt-manager-0.9.0-6.el6.x86_6
python-virtinst-0.600.0-5.el6.noarch

Verified with:
kernel-2.6.32-220.el6.x86_64
libvirt-0.9.10-0rc2.el6.x86_64
python-virtinst-0.600.0-7.el6.noarch
virt-manager-0.9.0-9.el6.x86_64

Steps:
1.  create an empty directory
2.  create a new virtual machine
3.  select managed or other existing storage
4.  browse local to empty directory
5.  input a new file name "new.img"
6.  click open button
7.  the new.img is created under the empty directory
# qemu-img info new.img
image: new.img
file format: raw
virtual size: 8.0G (8589934592 bytes)
disk size: 0

Changed the status to VERIFIED

Comment 9 Cole Robinson 2012-06-12 15:25:02 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed

Comment 11 errata-xmlrpc 2012-06-20 12:35:56 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.

http://rhn.redhat.com/errata/RHBA-2012-0785.html


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