[ovirt-users] 3.4: VDSM Memory consumption

[Francesco Romani]

----- Original Message -----
> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
> To: "Francesco Romani" <fromani at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, users at ovirt.org
> Sent: Monday, September 29, 2014 2:54:13 PM
> Subject: Re: [ovirt-users]	3.4: VDSM Memory consumption
> 
> Hello Francesco,
> 
> On 29.09.2014 13:55, Francesco Romani wrote:
> > ----- Original Message -----
> >> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
> >> To: "Dan Kenigsberg" <danken at redhat.com>
> >> Cc: users at ovirt.org
> >> Sent: Monday, September 29, 2014 12:25:22 PM
> >> Subject: Re: [ovirt-users]	3.4: VDSM Memory consumption
> >>
> >> Dan,
> >>
> >> I just reply to the list since I do not want to clutter BZ:
> >>
> >> While migrating VMs is easy (and the sampling is already running), can
> >> someone tell me the correct polling port to block with iptables?
> >>
> >> Thanks,
> > Hi Daniel,
> >
> > there is indeed a memory profiling patch under discussion:
> > http://gerrit.ovirt.org/#/c/32019/
> >
> > but for your case we'll need a backport to 3.4.x and clearer install
> > instructions,
> > which I'll prepare as soon as possible.
> I updated the BZ (and are now blocking 54321/tcp on one of my hosts).
> and verified it is not reachable. As  general info: This system I am
> using is my LAB / Test / eval setup for a final deployment for ovirt
> (then 3.5) in production; so it will go away some time in the future (a
> few weeks / months). If I am the only one experiencing this problem then
> you might be better of allocating resources elsewhere ;)

Thanks for your understanding :)

Unfortunately it is true that developer resources aren't so abundant,
but it is also true that memleaks should never be discarded easily and without
due investigation, considering the nature and the role of VDSM.

So, I'm all in for further investigation regarding this issue.

> > As for your question: if I understood correctly what you are asking
> > (still catching up the thread), if you are trying to rule out the stats
> > polling
> > made by Engine to this bad leak, one simple way to test is just to shutdown
> > Engine,
> > and let VDSMs run unguarded on hypervisors. You'll be able to command these
> > VDSMs using vdsClient or restarting Engine.
> As I said in my BZ comment this is not an option right now, but if
> understand the matter correctly IPTABLES reject should ultimately do the
> same?

Definitely yes! Just do whatever it is more convenient for you.

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani