Bug 684848

Possibly related: 'virsh -c ""' and 'virsh connect ""' should both work as a request to connect to the default URI.

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.

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 5 is a duplicate of bug 684655; however, comment 4 regarding making 'virsh' smarter about default connections is worth independently fixing.

Upstream patch posted:
https://www.redhat.com/archives/libvir-list/2011-March/msg00633.html

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.

This should be fixed by the libvirt-0.9.2-1.el6 rebase

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 #

Set it as VERIFIED per comment13

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