Bug 766463

Summary: virt-manager: Browse Local disabled on AddHardware->Filesystems UI
Product: [Community] Virtualization Tools Reporter: Deepak C Shetty <deepakcs>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, crobinso, sankarshan, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-30 03:20:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
virt-manager --debug log none

Description Deepak C Shetty 2011-12-12 05:50:49 UTC
Created attachment 545586 [details]
virt-manager --debug log

Description of problem:
Browse Local disabled on AddHardware->Filesystems UI.
I am running virt-manager on the host, and in the FileSystem UI, 'Browse Local'
button is always disabled. I need it to be enabled in order to select a host path that will be exported to the guest.

I am opening this bug as a follow up on the below email thread...
https://www.redhat.com/archives/virt-tools-list/2011-November/msg00025.html

Version-Release number of selected component (if applicable):
Attaching the virt-manager --debug log.

How reproducible:
Always

Steps to Reproduce:
1. Start virt-manager, select a existing VM/Domain
2. Click on the "i" button to get info of the VM. Click on "Add Hardware"
3. Select "Filesystem" and click on the "browse" button against "source" field
4. In the storage browser that appears, "browse local" is disabled. I need it to be enabled, in order to select the local host path that i need to be exported to the guest.
  
Actual results:
See #4 above. ( basically browse local disabled )

Expected results:
See #4 above ( browse local should be enabled )

Additional info:

Comment 1 Deepak C Shetty 2012-01-28 08:20:33 UTC
Hi Cole,
    I feel the is_local function needs to be enhanced to take care of
URIs which contain localhost / 127.0.0.1 to return true in such cases also
It currently returns true only when URI has qemu:///system, which is not entirely correct ? This is what i feel is the reason why Browse Local is not getting enabled in the above use case.

Comment 2 Cole Robinson 2012-01-30 03:20:16 UTC
It's true that doing qemu+ssh:///root@localhost/system or similar is a 'localhost' connection, but I deliberately do not want to detect that in virt-manager. For one I can't think of a valid use case for doing it in production, but the primary reason is that having that URI treated as 'remote' by virt-manager makes life much easier when doing development/testing of the UI when handling a remote connection. It's unlikely that this will change, so closing as NOTABUG.

But out of curiousity, is there some reason you need to connect like this? Or were you just testing and thought it should be fixed.

Comment 3 Deepak C Shetty 2012-01-31 08:46:32 UTC
Hi Cole,
   Firstly qemu:///system never worked for me, it keeps giving me some or the other error related to TLS and/or cert/key setup. So i moved to using qemu+tcp:///system, which also gave some error( i dont remember right now) so using qemu+tcp://localhost/system always worked, hence i stick to that.  Also if i remember correctly from the VMM GUI is there a way to make qemu+tcp:///system... i guess not, bcos unless you select remote, it does not show up the tcp/ssh options ... so wondering if people need qemu+tcp the only way to do is to select remote but enter localhost in the UI, in which case they would expect the Browse Local to be enabled, since they entered localhost/127.0.01. I feel from a usability perspective too, is_local should be made to work with all forms or local host representation.

Comment 4 Cole Robinson 2012-01-31 15:32:52 UTC
It sounds like the real problem here is that qemu:///system wasn't working for you. We should find out way: that's the way pretty much every virt-manager user connects to local qemu and it works for most of them (otherwise I'd get a million bug reports about it :) )

It sounds like you were connecting to local qemu with a hostname in the URI to work around a bug: that's not a valid use case for changing the is_local detection, and I still can't think of a valid usecase for connecting remotely to localhost besides developers wanting to test the UI with a remote connection, in which case I don't think is_local should change.

What's the error you get if you try

virsh --connect qemu:///system

as a regular user?