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

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Tue, Jan 15, 2008 at 08:06:58AM +0000, Keir Fraser wrote:

> >> 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>).
> > 
> > Am I missing something obvious here?
> 
> It depends on your test case. If you save/restore the same VM repeatedly
> then in the old case you would see no leak. But youw ould still see a leak
> if you created/destroyed lots of different VMs.

I don't think so - domain destruction already removes the /vm path (I'd
confused myself here). I just verified this with our 3.1 bits.

Your other email:

> Sure. Nothing in xenstore is now supposed to persist across domain
> restarts/migrates/etc. xend stores info about managed domains in a
> separate database. All xenstore info is ephemeral.

The VIF MAC is the perfect counter-example to this, is it not? It must
remain the same across a domain's existence, even if it's randomly
generated. How do you propose to fix the bug if you don't have /vm ?
(I'm not so sure that any of the rest of /vm is /really/ needed,
but that depends on how xend behaves on restart)

regards
john

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