Hide Forgot
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:
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.
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.
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.
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?