[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.