Re: That xenstored console leak...

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Jan 14, 2008 at 10:55:37PM +0000, John Levon wrote:
> On Mon, Jan 14, 2008 at 09:54:50PM +0000, Keir Fraser wrote:
> 
> > >> 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.
> > > 
> > > The lack of the latter explains the former - because each instance has a
> > > unique /vm path, there's nothing that ever cleans up the older path
> > > contents (image etc.).  Right?
> > 
> > I don't understand what you mean. There's no code to delete the entire /vm
> > path, regardless of whether the path is /vm/<uuid>/ or /vm/<uuid>-<number>
> > (I'm pretty sure).
> 
> The old code re-used the same /vm/<uuid>/ path, so there was no leak.
> The new code creates a completely new /vm/<uuid>-<number> path, leaking the
> old one (/vm/<uuid>-<oldnumber>).

Yes, I noticed that too - its rather peculiar - the idea of the /vm/ 
hierarchy was that it was persistent for any individual VM, across creation
attempts. If we append <number> on the path each time it ceases to be 
persistent and we might as well just kill off /vm and use /local/<domid>
for everything.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|