Re: That xenstored console leak...

[Jim Fehlig <jfehlig@novell.com>]

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