WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH]: Fix xm block-detach

To: Chris Lalancette <clalance@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH]: Fix xm block-detach
From: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Date: Tue, 02 Dec 2008 23:02:52 +0900
Cc:
Delivery-date: Tue, 02 Dec 2008 06:03:22 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49352971.6020605@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49352971.6020605@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Chris,

I could not reproduce the problem by using the latest xen-unstable.

I also found a problem of block tap devices included by c/s 18562, 
then I have fixed the problem by c/s 18843.  But the problem occurred 
by using xm shutdown or xm destroy or etc, not xm block-detach.

Could you try xm block-detach by using the latest xen-unstable?

Best regards,
 Kan

Tue, 02 Dec 2008 13:26:25 +0100, Chris Lalancette wrote:

>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@xxxxxxxxxx>
>
>-------------------------------text/plain-------------------------------
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel


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

<Prev in Thread] Current Thread [Next in Thread>