Bug 734529

Summary:	Adding storage via file browser is inflexible and differs from 5.6 behaviour
Product:	Red Hat Enterprise Linux 6	Reporter:	James B. Byrne <byrnejb>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0	CC:	jwu, mzhan, rwu, zpeng
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	No documentation needed	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 12:35:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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