thats strange, as we ensure we close down the connection after each request

see https://github.com/theforeman/foreman/blob/0.4-stable/app/controllers/hypervisors/guests_controller.rb#L6

maybe there is a bug in the disconnect method.

Yes, I gave a quick look at the code, which looks fine at first sigh (but I am no Rubyist).

How can I activate logging to try to find what is going on? Maybe adding some print statements somewhere?

Humm I've digged a bit, and the disconnect method of Virt.Connection is properly called. Thus the problem may reside in the ruby wrapper for libvirt (I use the Debian package, aka libvirt-ruby1.8 0.0.7-1), unless a reference to the libvirt connection instance is kept somewhere preventing it from being garbage collected, or some similar stuff (not sure this is relevant here).

I have compiled libvirt-ruby 0.4.0 and the behavior seems much better. TCP connections go in state TIME_WAIT after a short amount of time, then are closed completely.

I'll make more tests tomorrow, but I think I have the culprit...

Ohad, my virt ESX code tried to fix this issue. I think we should be caching the libvirt object anyways instead of open/closing the connection so many times. Every time virt opens a connection it has to make so many calls to libvirt.

Ohad Levy wrote:

hmm.. so can we mark this as resolved?

I did not have time to make extensive tests (as I wanted to do), but it looks that this can be marked as solved.

Corey Osman wrote:

Ohad, my virt ESX code tried to fix this issue. I think we should be caching the libvirt object anyways instead of open/closing the connection so many times. Every time virt opens a connection it has to make so many calls to libvirt.

Corey I agree, however, as we are planning to swap to using fog for libvirt (and probably use virt within fog) this might be a different context for discussion <-- Thanks!