[Xen-devel] HVM restart issue

["Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>]

Recently I found HVM restart (destroy + start) is very slowly and the 
reason is the change to xen-hotplug-cleanup (see below).
When HVM is destroyed, backend vbd/vnif drivers will not be notified 
until /local/domain/hvm_id is removed in xenstore. udev event is then 
generated and xen-hotplug-cleanup is called. So the first xenstore-read 
will always fail and leave rest undone and xenstore unclean. Suggestion 
is to move it after backend/frontend removal.
Another interesting thing is that in function claim_lock, "release_lock 
$1; sigerr" is registered as ERR handler. However it seems its scope in 
effect is within the function. After claim_lock returns, the handler 
restores to the previous one ("sigerr") on my machine. So when the above 
error happens, the first script exits without calling release_lock. It 
keeps the following script waiting. Is this a correct BASH behavior?
Thanks,
xiaowei

diff -r 16fc70ce40a7 -r b3774712e654 tools/hotplug/Linux/xen-hotplug-cleanup
--- a/tools/hotplug/Linux/xen-hotplug-cleanup   Mon Mar 02 10:32:32 2009 
+0000
+++ b/tools/hotplug/Linux/xen-hotplug-cleanup   Mon Mar 02 10:34:37 2009 
+0000
@@ -11,6 +11,13 @@ dir=$(dirname "$0")
 # This is pretty horrible, but there's not really a nicer way of 
solving this.
 claim_lock "block"

+# split backend/DEVCLASS/VMID/DEVID on slashes
+path_array=( ${XENBUS_PATH//\// } )
+# get /vm/UUID path
+vm=$(xenstore-read "/local/domain/${path_array[2]}/vm")
+# construct /vm/UUID/device/DEVCLASS/DEVID
+vm_dev="$vm/device/${path_array[1]}/${path_array[3]}"
+
 # remove device frontend store entries
 xenstore-rm -t \
   $(xenstore-read "$XENBUS_PATH/frontend" 2>/dev/null) 2>/dev/null || true
@@ -19,4 +26,7 @@ xenstore-rm -t "$XENBUS_PATH"        2>/
 xenstore-rm -t "$XENBUS_PATH"        2>/dev/null || true
 xenstore-rm -t "error/$XENBUS_PATH"  2>/dev/null || true

+# remove device path from /vm/UUID
+xenstore-rm -t "$vm_dev" 2>/dev/null || true
+
 release_lock "block"


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