FOUND IT!

someone decided to edit /etc/libvirt/libvirtd.conf and uncommented out the listen_tls = 0 line

That person has been thoroughly beaten around the head and shoulder area.

Thanks for the great info.... libvirtd is now running as expected.

Since I won't be doing any NAT the virbr0 has been deleted succesfully.

Thanks again.
 
Denny Snyder
Systems Engineer
IT@Johns Hopkins
5801 Smith Ave Suite 3110C
Baltimore, MD 21209
(410) 735-7613: DESK
(410) 735-4660: FAX

On 10/21/2009 03:20 PM, Denny Snyder wrote:
UPDATE:

Found the following in the /var/log/messages:
Oct 21 15:02:50 jhsympa2-base libvirtd: 15:02:50.227: error : Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
Oct 21 15:09:29 jhsympa2-base libvirtd: 15:09:29.910: warning : Shutting down on signal 2
Oct 21 15:10:20 jhsympa2-base libvirtd: 15:10:20.628: error : Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory

This didn't happen before hand and I haven't changed anything to say use TLS or SSL or anything....

there definitely isn't anything in the  /etc/pki/CA directory...  I'll try generating a cert and see what happens.
 
Denny Snyder
Systems Engineer
IT@Johns Hopkins
5801 Smith Ave Suite 3110C
Baltimore, MD 21209
(410) 735-7613: DESK
(410) 735-4660: FAX

On 10/21/2009 02:55 PM, Daniel P. Berrange wrote: 
On Wed, Oct 21, 2009 at 11:36:50AM -0400, Denny Snyder wrote:
  
   Hi all,

   I had installed RHEL 5 x86_64 with virtualization right off the bat. 
   Everything ran beautifully with two Xen guests (also RHEL 5.)  All 3 IPs
   (host and 2 guests) were in the same subnet.

   Then I had to change all the IP addresses to a different subnet (but again
   all 3 within the same subnet - trying to stay away from 802.1q stuff)... 
   so I modified each guest's /etc/hosts, etc/sysconfig/network,
   etc/sysconfig/network-scripts/ifcfg-eth0 and then shutdown both guests. 
   Then modified the configs on the host and rebooted.

   When it boots now it seems like it's fine but there is no network
   connectivity and the default route is pointing to the virbr0 interface!!
   ifconfig shows eth0 but without an IP address

   If I do a 'service network restart' then everything works fine again, eth0
   has the correct IP and the default route is in place.  At that point
   everything seems fine with the exception of:

   I get this every two minutes now:
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: warning : Failed to find the network: Is the daemon running ?
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: warning : Failed to find a node driver: Is the libvirtd daemon
   running ?
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: warning : Failed to find the network: Is the daemon running ?
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: Remote error : unable to connect to
   '/var/run/libvirt/libvirt-sock': Connection refused
   libvir: warning : Failed to find a node driver: Is the libvirtd daemon
   running ?
    
Tis means the libvirtd isn't running

  
   'service libvirtd status' shows:
   libvirtd dead but subsys locked

    
And this obviously confirms it.

  
   I do notice that when I launch virt-manager there is nothing listed in the
   'virtual network' tab - it's all greyed out.
    
Due to libvirtd not running

  
   another error I noticed is:
   virsh net-list --all
   error: Failed to list active networks
   error: this function is not supported by the hypervisor:
   virConnectNumOfNetworks
    
Again same thing


  
   Where am I to fix this weirdness?  Changing IPs shouldn't involve all of
   this!  Especially when I'm only changing eth0 and they are all in the same
   subnet as before and nothing else was modified.
    
Yeah its very odd that this is related. 

At least if you do  'service libvirtd stop' to clear the dead PID file,
and then 'service libvirtd start' it should hopefully be back to normal.
If it still crashes, then best to try running /usr/sbin/libvirtd
manually, or under gdb/valgrind and capture a trace


Once libvirtd is running you can disable virbr0 with

  virsh net-destroy default
  virsh net-autostart --disable default

which will stop 'virbr0' running / being created - its only required if
you want to use NAT, not for bridging

Regards,
Daniel