| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] That xenstored console leak...
Keir Fraser wrote:
>> 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 ...
>>
>
> Isn't having two domains (even from the same vm) pointing at the same /vm/
> path a recipe for further bugs? Most of the lowlevel xend code doesn't seem
> to understand the concept that domains can map to the same vm, and could
> hence tread on each others toes via the /vm/ path.
>
> If we revert the two patches, what happens when you create/destroy lots of
> domains all with different uuids? I expect the leak will still exist in that
> case.
>
Sorry for the delay. I'm not sure why you think that the leak would
still exist with those changesets reverted. 15957 (and subsequently
15967) introduced the leak by creating a whole new /vm/<uuid>-<num>
path, leaving the previous path orphaned. But I certainly don't claim
to be an expert on this code so perhaps I'm not understanding your concern.
Nevertheless, I created/destroyed lots of domains on 3.2 with those
changesets reverted and do not see the leak. However I wouldn't expect
so since each domain has a different uuid and hence a different
/vm/<uuid> path, which is removed when the domain is destroyed.
BTW, with those changesets /vm/<uuid> path is leaked on save/restore,
reboot, and localhost migration. Perhaps the source domain in these
operations should be removing its /vm path on destruction?
Jim
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home