From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: That xenstored console leak... Date: Mon, 14 Jan 2008 12:27:10 -0700 Message-ID: <478BB78E.5020709@novell.com> References: <20080111173914.GA24773@totally.trollied.org.uk> <4787C804.4010909@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4787C804.4010909@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: John Levon List-Id: xen-devel@lists.xenproject.org Jim Fehlig wrote: > John Levon wrote: > >> Here's what I'm using to fix it in 3.1. Obviously too risky for 3.2 now, >> and anyway, there's a much more serious problem in 3.2 - entire /vm/ >> entries are leaked on domU reboot! I haven't got round to debugging that >> one yet since it's not present in 3.1, but it really should be fixed >> >> > > I'm unable to reproduce the console leak on 3.2. I have tried rebooting > managed PV domU's several times with no orphaned console entries - using > 'xm reboot' and rebooting within the guest itself. > > I do however see the entire /vm/ nodes leaking and agree that this > is a rather serious bug as it could eventually cause swap thrashing in > dom0 [1]. E.g. after 3 reboots of PV domU xenstore contains > > vm > faa7647e-142b-74c7-dc72-efd57fe6d0ef-1 = "" > image = "(linux (kernel ) (args 'mem=512M ') (device_model > /usr/lib64/xen/bin/qemu\..." > ostype = "linux" > ... > faa7647e-142b-74c7-dc72-efd57fe6d0ef = "" > image = "(linux (kernel ) (args 'mem=512M ') (device_model > /usr/lib64/xen/bin/qemu\..." > ostype = "linux" > ... > faa7647e-142b-74c7-dc72-efd57fe6d0ef-2 = "" > image = "(linux (kernel ) (args 'mem=512M ') (device_model > /usr/lib64/xen/bin/qemu\..." > ostype = "linux" > ... > > This leak is much worse than a single device leaking :-(. I'll have a > look but may be a day or two before I can get to it. > > Jim > > [1] http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00641.html > After some investigation I have found that the /vm/ leak is caused by c/s 15957 (later modified by c/s 15967). Reverting these changesets removes the leak on 3.2 RC4. Further, when reverting c/s 15957 I am not seeing the issue it claims to fix - i.e. I am not losing the vif mac address when doing localhost migrations of PV or HVM domU's. Keir - under what circumstances was vif mac address being lost? I am unable to reproduce that behavior on RC4 with 15967 and 15957 reverted. Regards, Jim