WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] That xenstored console leak...

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] That xenstored console leak...
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Mon, 14 Jan 2008 12:27:10 -0700
Cc: John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Jan 2008 11:27:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4787C804.4010909@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080111173914.GA24773@xxxxxxxxxxxxxxxxxxxxxxx> <4787C804.4010909@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.8 (X11/20060911)
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/<uuid> 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/<uuid> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel