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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] That xenstored console leak...
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Mon, 14 Jan 2008 16:49:20 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Daniel P. Berrange" <berrange@xxxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Jan 2008 16:10:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: C3B184C2.12262%Keir.Fraser@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.8 (X11/20060911)
Keir Fraser wrote:
> On 14/1/08 20:08, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:
>
>   
>> I see the behaviour in 3.1 with HVM domains. If I live migrate twice,
>> then the MAC address is lost, and a new random one is generated:
>>
>> I don't have to do anything "special", this happens every time on 3.1. I
>> presume that the troublesome changeset fixes this exact problem.
>>     
>
> Yes, device controllers clean up by deleting /vm/<uuid>/path/to/device. This
> aliases with the new domain's device information (because they're really the
> same vm) and so when the old domain is cleaned up the new domain loses
> information. Disambiguating with an extra level of indirection seemed the
> simplest fix for this. I'm not sure why this leads to xenstore leaks.
>
> When a domain is finally garbage collected in xend, perhaps we should delete
> its entire /vm/<uuid>/<unique-number>? That would seem a nice and reasonable
> catch-all.
>   

Reverting changesets 15967 and 15957 in addition to the attached patch
fixes the leak and allows multiple localhost migrations.  I'm not sure
what we get by nuking /vm/<uuid>/device/vif/<dev_num> anyway - other
than the problems we're seeing :-). vif appears to be the only device
stored in the /vm/<uuid>/device path anyway.

I will continue testing with this setup ...

Jim

diff -r 533a8e6cebd0 tools/python/xen/xend/server/DevController.py
--- a/tools/python/xen/xend/server/DevController.py     Sat Jan 12 11:26:04 
2008 +0000
+++ b/tools/python/xen/xend/server/DevController.py     Mon Jan 14 16:38:18 
2008 -0700
@@ -237,7 +237,6 @@ class DevController:
                 xstransact.Remove(backpath)
             xstransact.Remove(frontpath)
 
-        self.vm._removeVm("device/%s/%d" % (self.deviceClass, dev))
 
     def configurations(self, transaction = None):
         return map(lambda x: self.configuration(x, transaction), 
self.deviceIDs(transaction))
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel