RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 684848 - virsh connect URI mistakenly tries to open default connection
Summary: virsh connect URI mistakenly tries to open default connection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 605660 684655
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-14 16:22 UTC by Eric Blake
Modified: 2011-12-06 10:57 UTC (History)
7 users (show)

Fixed In Version: libvirt-0.9.2-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:57:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description Eric Blake 2011-03-14 16:22:06 UTC 
Description of problem:
virsh is not supposed to open the default connection unless it encounters a command that requires a connection and does not already have one open.  Therefore, 'virsh connect test:///default' should succeed, and does so on F14 libvirt-client-0.8.3-4.fd14.x86_64.  However, a regression appeared where virsh now always tries to open the default connection.

Version-Release number of selected component (if applicable):
libvirt-client-0.8.7-11.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. as non-root: virsh connect test:///default; echo $?
  
Actual results:
$ virsh connect test:///default; echo $?
error: cannot recv data: : Connection reset by peer
error: failed to connect to the hypervisor
1

Expected results:
$ virsh connect test:///default; echo $?
0

Additional info:
Originally reported by the Common Criteria list.
Comment 3 Eric Blake 2011-03-14 16:27:00 UTC 
Possibly related: 'virsh -c ""' and 'virsh connect ""' should both work as a request to connect to the default URI.
Comment 4 Eric Blake 2011-03-14 18:46:33 UTC 
Hmm, after further investigation, it looks like 'virsh connect URI' has _always_ first connected to the default connection, then disconnected and reconnected to the specified URI.  Of course, this is wasteful, so it is still worth patching.

The regression that I'm seeing on RHEL 6 appears to be that qemu:///session is no longer working out of the box, rather than any change in virsh itself.  I'm now trying to track down why qemu:///session is erroring out for RHEL but working for Fedora.
Comment 5 Eric Blake 2011-03-14 19:36:17 UTC 
This appears to be the real regression - auto-starting the session daemon fails:

$ /usr/sbin/libvirtd --timeout=30
13:06:02.502: 24377: info : libvirt version: 0.8.7, package: 10.el6 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2011-03-07-14:14:56, x86-003.build.bos.redhat.com)
13:06:02.502: 24377: error : virStateInitialize:1022 : Initialization of udev state driver failed
13:06:02.520: 24377: warning : qemudStartup:1733 : Unable to create cgroup for driver: Permission denied
13:06:02.771: 24377: error : main:3305 : Driver state initialization failed
13:06:02.771: 24379: warning : qemudDispatchSignalEvent:403 : Shutting down on signal 3
Comment 6 Eric Blake 2011-03-14 20:42:19 UTC 
comment 5 is a duplicate of bug 684655; however, comment 4 regarding making 'virsh' smarter about default connections is worth independently fixing.
Comment 7 Eric Blake 2011-03-14 21:11:39 UTC 
Upstream patch posted:
https://www.redhat.com/archives/libvir-list/2011-March/msg00633.html
Comment 11 Dave Allan 2011-06-09 14:58:09 UTC 
commit d218344e6c1afce5788d7f72b78859219c50a3de
Author: Eric Blake <eblake>
Date:   Mon Mar 14 14:30:24 2011 -0600

    virsh: optimize creation of default connection
    
    Ramon de Carvalho Valle reported a problem with:
    virsh connect qemu:///system
    as a non-root user.  The real root problem appears to be a regression
    in libvirtd being auto-started on the default qemu:///session URI;
    however, the symptom points to an independent flaw in virsh - we
    shouldn't be wasting efforts on making a connection if we aren't going
    to be using that connection.  Fixing virsh avoids Ramon's issue, while
    I work in the meantime to fix the real libvirtd regression.
    
    This patch looks big, but that's because 'gcc -Wmissing-field-initializers'
    gets triggered by './autobuild.sh --enable-compile-warnings=error', so I
    had to add 0 initialization to everyone (rather than my preference of
    just adding the non-zero flags to virshCmds and to cmdConnect).
    
    Meanwhile, if you use 'virsh -c URI', the connection must succeed; this
    patch _only_ optimizes the default connection to be deferred to a later
    point where we know if a particular command to be run needs a connection.
    
    * tools/virsh.c (VSH_CMD_FLAG_NOCONNECT): New flag.
    (vshCmdDef): Add new flags field.
    (vshCommandRun): Honor new flag.
    (domManagementCmds, domMonitoringCmds, storagePoolCmds)
    (storageVolCmds, networkCmds, nodedevCmds, ifaceCmds)
    (nwfilterCmds, secretCmds, virshCmds, snapshotCmds)
    (hostAndHypervisorCmds): Populate new field.
    (vshReconnect): Don't warn on initial connection.
Comment 12 Daniel Veillard 2011-06-23 02:51:37 UTC 
This should be fixed by the libvirt-0.9.2-1.el6 rebase
Comment 13 zhanghaiyan 2011-06-24 06:42:52 UTC 
Reproduced this bug with old package libvirt-0.8.7-11.el6.x86_64.rpm
- 2.6.32-156.el6.x86_64
- qemu-kvm-0.12.1.2-2.165.el6.x86_64

$ virsh connect test:///default
error: cannot recv data: : Connection reset by peer
error: failed to connect to the hypervisor

Verified this bug pass with new package libvirt-0.9.2-1.el6.x86_64
- 2.6.32-156.el6.x86_64
- qemu-kvm-0.12.1.2-2.165.el6.x86_64

[yoyo@localhost ~]$ virsh connect test:///default

[yoyo@localhost ~]$ virsh -c test:///default
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh #
Comment 15 Rita Wu 2011-07-06 10:25:21 UTC 
Set it as VERIFIED per comment13
Comment 16 errata-xmlrpc 2011-12-06 10:57:51 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-2011-1513.html
Note You need to log in before you can comment on or make changes to this bug.