Hi List, In the process of integrating dm-userspace into the xen tools, we introduced a situation that (to my knowledge) does not normally occur with any of the in-tree block device backends: Our daemon takes a little bit of time to shutdown once it has received the signal to terminate. This means that if you quickly destroy and re-create a domain, the daemon for the previous instance''s block device could be still hanging around when the new instance''s device is created. This is because "xm destroy" does not wait for the devices to be fully cleaned up before returning. Even if we put a poll loop in /etc/xen/scripts/block, the call to destroy a domain does not wait for it to complete. With the existing tools, I think it is possible to hit this issue if you have a heavily loaded system that is using every single loop device. A quick destroy and re-create could fail to find a free loop device because the one used by the just-killed domain has not been freed up yet. So, what would be the best way to resolve this? My thought was to make xend wait for all block devices to write another key into the store when the backend script has completed, and make XendDomainInfo.destroy() wait for all of those to come in before returning. Is that a valid solution? Perhaps we would only do that for certain device types, like dmu: and file:? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel