Bug 1377244

Summary: --show-DIALOG-WINDOW doesn't imply --no-conn-autostart option
Product: Red Hat Enterprise Linux 7 Reporter: Xiaodai Wang <xiaodwan>
Component: virt-managerAssignee: Pavel Hrdina <phrdina>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: juzhou, mxie, mzhang, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-manager-1.4.1-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 21:02:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Xiaodai Wang 2016-09-19 09:45:06 UTC
Description of problem:
--show-DIALOG-WINDOW doesn't imply --no-conn-autostart option

Version-Release number of selected component (if applicable):
virt-manager-1.4.0-2.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Check man page of virt-manager, --show-DIALOG-WINDOW implies --no-conn-autostart.
       --show-DIALOG-WINDOW
           Display the corresponding "DIALOG-WINDOW" when launching "virt-manager". This function implies --no-conn-autostart and the manager window will not be shown at startup in this
           case.
2. Add two connections by virt-manager and make them auto connect.
3. Run "virt-manager --show-DIALOG-WINDOW -c qemu:///system"

Actual results:
A dialog pops up and asks for another connection's password to connect after connecting to qemu:///system.

Expected results:
--no-conn-autostart should be implied and only qemu:///system should be connected.

Additional info

Comment 1 Pavel Hrdina 2017-01-17 16:59:35 UTC
Upstream commit:

commit ceda7a5dbfcd9b94bbe65916e7f41f213d9d3629
Author: Pavel Hrdina <phrdina>
Date:   Tue Jan 17 15:34:14 2017 +0100

    virt-manager: don't autostart other connection if --show-* was specified

Comment 3 zhoujunqin 2017-03-16 09:45:57 UTC
I can reproduce this bug with package:
virt-manager-1.4.0-2.el7.noarch

Then try to verify this bug with new build:
virt-manager-1.4.1-1.el7.noarch
virt-install-1.4.1-1.el7.noarch
virt-manager-common-1.4.1-1.el7.noarch
libvirt-3.1.0-2.el7.x86_64

Steps:
Scenario-1 Quit whole virt-manager window.
1. Add two connections by virt-manager and make them Autoconnect.
   eg: QEMU/KVM & QEMU/KVM: 10.66.4.XX
   Then close virt-manager.
2. Run "virt-manager --show-DIALOG-WINDOW -c qemu:///system".
2.1 
# virt-manager  -c qemu:///system --show-domain-creator
Result: Just "New VM(on localhost.localdomain)" window pops up.
2.2
# virt-manager -c qemu:///system --show-domain-editor=myVm2raw
Result: Vm details window pop up.
2.3
# virt-manager -c qemu:///system --show-domain-performance=myVm2raw
Result: Vm details window pop up and show performance tab.
2.4
# virt-manager -c qemu:///system --show-domain-console=myVm2raw
Result: Vm's console pop up
2.5
# virt-manager -c qemu:///system --show-host-summary
Result:  Host details window pop up and show overview tab.

Result:No dialog pops up and asks for another connection's password to connect after connecting to qemu:///system.


Scenario-2 Leave virt-manger main window.
1. Add two connections by virt-manager and make them Autoconnect.
   eg: QEMU/KVM & QEMU/KVM: 10.66.4.XX
   Then disconnect both connections(by right click connection->click "Disconnect")

2. Run "virt-manager --show-DIALOG-WINDOW -c qemu:///system".
2.1 # virt-manager  -c qemu:///system --show-domain-creator
Result: 2.1.1 "New VM(on localhost.localdomain)" window pops up.
        2.2.2 No dialog pops up and asks for another connection's password to connect after connecting to qemu:///system in virt-manager main window.
2.2 Disconnect connection "QEMU/KVM", then Repeat step2.2 to step2.5 in Scenario-1 again.

Result: No dialog pops up and asks for another connection's password to connect after connecting to qemu:///system.

So move this bug from ON_QA to VERIFIED.

Comment 4 errata-xmlrpc 2017-08-01 21:02:03 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.

https://access.redhat.com/errata/RHBA-2017:2072