All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Lalancette <clalance@redhat.com>
To: xen-devel@lists.xensource.com
Subject: [PATCH]: Fix xm block-detach
Date: Tue, 02 Dec 2008 13:26:25 +0100	[thread overview]
Message-ID: <49352971.6020605@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

All,
     The recent changes to where xenstore stores data about domains (c/s 18562,
in particular) seem to have broken xm block-detach.  What happens is that
attaching a disk works just fine, but detaching a disk ends with:

Error: 51776 not connected
Usage: xm block-detach <Domain> <DevId> [-f|--force]

Destroy a domain's virtual block device.

The problem basically boils down to where the new code is placing the xenstore
entries.  Previously, it was storing them in /local/domain/<number>/device/vbd;
it is now storing them in /vm/UUID/device/tap.  The tap is wrong; tap describes
the backend, not the frontend, which should always be vbd.  The attached patch
fixes this by overriding deviceRoot() in the BlktapController class, similar to
how frontendRoot() is done, and then changing devicePath() to use deviceRoot().
 There is also a small fix for destroyDevice, to make sure we remove the proper
/vm/UUID/device/vbd entry on removal.
    With the patch in place, I was able to successfully block-attach and
block-detach disks again.  Note that I only tested this on RHEL-5 xend, which
has diverged quite a bit from upstream.  However, a quick glance at the code in
xen-unstable shows that this is probably a problem there as well; only testing
will tell for sure.

Signed-off-by: Chris Lalancette <clalance@redhat.com>

[-- Attachment #2: xen-fix-broken-blkdetach.patch --]
[-- Type: text/plain, Size: 1875 bytes --]

diff -urp xen-3.1.0-src.orig/tools/python/xen/xend/server/BlktapController.py xen-3.1.0-src/tools/python/xen/xend/server/BlktapController.py
--- xen-3.1.0-src.orig/tools/python/xen/xend/server/BlktapController.py	2008-12-02 13:07:04.000000000 +0100
+++ xen-3.1.0-src/tools/python/xen/xend/server/BlktapController.py	2008-12-02 13:08:32.000000000 +0100
@@ -16,6 +16,11 @@ class BlktapController(BlkifController):
     def __init__(self, vm):
         BlkifController.__init__(self, vm)
         
+    def deviceRoot(self):
+        """@see DevController#deviceRoot"""
+
+        return "%s/device/vbd" % self.vm.vmpath
+
     def frontendRoot(self):
         """@see DevController#frontendRoot"""
         
diff -urp xen-3.1.0-src.orig/tools/python/xen/xend/server/DevController.py xen-3.1.0-src/tools/python/xen/xend/server/DevController.py
--- xen-3.1.0-src.orig/tools/python/xen/xend/server/DevController.py	2008-12-02 13:07:04.000000000 +0100
+++ xen-3.1.0-src/tools/python/xen/xend/server/DevController.py	2008-12-02 13:09:25.000000000 +0100
@@ -221,6 +221,8 @@ class DevController:
         # drivers, so this ordering avoids a race).
         self.writeBackend(devid, 'online', "0")
         self.writeBackend(devid, 'state', str(xenbusState['Closing']))
+        devpath = self.devicePath(devid)
+        xstransact.Remove(devpath)
 
         if force:
             frontpath = self.frontendPath(devid)
@@ -487,8 +489,7 @@ class DevController:
     def devicePath(self, devid):
         """Return the /device entry of the given VM. We use it to store
         backend/frontend locations"""
-        return "%s/device/%s/%s" % (self.vm.vmpath,
-                                    self.deviceClass, devid)
+        return "%s/%s" % (self.deviceRoot(), devid)
 
 def hotplugStatusCallback(statusPath, ev, result):
     log.debug("hotplugStatusCallback %s.", statusPath)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

             reply	other threads:[~2008-12-02 12:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-02 12:26 Chris Lalancette [this message]
2008-12-02 14:02 ` [PATCH]: Fix xm block-detach Masaki Kanno
2008-12-02 14:20   ` Chris Lalancette
2008-12-02 16:24     ` Chris Lalancette
2008-12-03  2:41       ` Masaki Kanno
2008-12-03 15:46         ` Chris Lalancette

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=49352971.6020605@redhat.com \
    --to=clalance@redhat.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.