From: "Yang, Xiaowei" <xiaowei.yang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: HVM restart issue
Date: Thu, 12 Mar 2009 16:15:10 +0800 [thread overview]
Message-ID: <49B8C48E.902@intel.com> (raw)
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"
next reply other threads:[~2009-03-12 8:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 8:15 Yang, Xiaowei [this message]
2009-03-12 8:31 ` HVM restart issue Keir Fraser
2009-03-12 10:56 ` Boris Derzhavets
2009-03-12 11:18 ` Keir Fraser
2009-03-12 13:02 ` Boris Derzhavets
2009-03-12 15:03 ` Keir Fraser
2009-03-12 15:10 ` Boris Derzhavets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49B8C48E.902@intel.com \
--to=xiaowei.yang@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.