[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) regards john _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |