On 07/17/10 - 09:30:29PM, Jaromír Červenka wrote: > Good evening, > > could anybody explain me this, please? > > divinus:~ # virsh > error: cannot recv data: : Connection reset by peer > error: failed to connect to the hypervisor > divinus:~ # > > I am trying to imlement Chris's ruby-libvirt to my Ruby on Rails > application. First few connection to libvirt daemon (thru ruby-libvirt API) > from my app are ok, but then somethings happend and it's not possible to > connect anymore until I restart libvirt daemon manually by init.d script or > until I restart apache (or WEBrick). And it's not possible connect to virsh > from shell also! See messages above. > > When I try ruby-libvirt from bare Ruby script, everythig is fine - doesn't > matter how many times I connect. It's strange. > > Does anybody have experience with ruby-libvirt in RoR application? That is pretty strange. One way that I could imagine this happening is if libvirtd runs out of file descriptors (or some other resource), and then can't accept any new connections. There have been some bugs in libvirtd that cause that, though it could equally be that your objects aren't being garbage collected by the Ruby VM. What version of libvirtd are you testing against? If it's possible, I wonder if you can force a garbage collection run in ruby and see if that frees up any resources? -- Chris Lalancette

On 07/29/10 - 07:41:26PM, Jaromír Červenka wrote: > Hi, > > i think that I know where is the problem. My "messages" log says: > > Jul 29 19:36:41 divinus libvirtd: 19:36:41.032: error : > qemudDispatchServer:1315 : Too many active clients (100), dropping > connection > > It looks like that ruby-libvirt doesn't closing connection, when it's > running under passenger/rails/apache. The "100" is my defined number in > /etc/libvirt/libvirtd.conf Ah, OK. So then the question becomes whether the problem is in the ruby bindings not releasing the object in certain circumstances, or in rails holding onto the object too long. Unfortunately I'm not really that familiar with rails or passenger, so I'm not entirely sure how to figure out where the problem is. I'll see if I can do a bit of testing and look at object lifetimes from the point-of-view of ruby-libvirt to try and eliminate that from the equation.

Ah, OK. So then the question becomes whether the problem is in the ruby bindings not releasing the object in certain circumstances, or in rails holding onto the object too long. Unfortunately I'm not really that familiar with rails or passenger, so I'm not entirely sure how to figure out where the problem is. I'll see if I can do a bit of testing and look at object lifetimes from the point-of-view of ruby-libvirt to try and eliminate that from the equation.

On 11/21/10 - 11:25:09PM, Pawel Krzesniak wrote: > On 29.07.2010 20:32, Chris Lalancette wrote: > >Ah, OK. So then the question becomes whether the problem is in the ruby > >bindings not releasing the object in certain circumstances, or in rails > >holding onto the object too long. Unfortunately I'm not really that familiar > >with rails or passenger, so I'm not entirely sure how to figure out where the > >problem is. > > > >I'll see if I can do a bit of testing and look at object lifetimes from the > >point-of-view of ruby-libvirt to try and eliminate that from the equation. > > following testcase confirms that problem is in bindings itself: OK, I see what the problem is. I'm not entirely sure if it is actually a problem in the bindings, but the behavior is a bit surprising in a garbage-collected language. See below. > ree-1.8.7-2010.02 > require 'libvirt' > => true > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > libvirt-sock` > 0 > => nil > ree-1.8.7-2010.02 > c = Libvirt::open 'qemu:///system' > => #<Libvirt::Connect:0x265b718> > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > libvirt-sock` > 1 After this point, we have a single connection. > => nil > ree-1.8.7-2010.02 > d = c.lookup_domain_by_name 'abc' > => #<Libvirt::Domain:0x2705128> > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > libvirt-sock` > 1 Still the same connection. > => nil > ree-1.8.7-2010.02 > c.close Here's where the problem is. Because you are doing c.close before cleaning up the domain object, the libvirt library keeps a connection open. If you do either: d = nil GC.start or d.free before the c.close, then everything would be cleaned up correctly. In terms of making this automatically happen during connection closing, I'm not entirely sure what we can (and should) do. I guess we could keep some sort of list of objects that "depend" on this connection object, and then during connection close free them all up. Does anyone know how the python bindings handle this?

On Tue, Nov 23, 2010 at 14:28, Chris Lalancette <clalance(a)redhat.com&gt; wrote: > In terms of making this automatically happen during connection closing, I'm > not entirely sure what we can (and should) do.  I guess we could keep some sort > of list of objects that "depend" on this connection object, and then during > connection close  free them all up. Does anyone know how the python bindings > handle this? python bindings work more or less the same way (see attachment). So conclusion is, that all objects must be free() before closing connection. It's not so intuitive, so maybe info about that should be somewhere in docs?