[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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,

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

>     The recent changes to where xenstore stores data about domains (c/s 
>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 
>entries.  Previously, it was storing them in /local/domain/<number>/device/
>it is now storing them in /vm/UUID/device/tap.  The tap is wrong; tap 
>the backend, not the frontend, which should always be vbd.  The attached 
>fixes this by overriding deviceRoot() in the BlktapController class, 
>similar to
>how frontendRoot() is done, and then changing devicePath() to use 
> There is also a small fix for destroyDevice, to make sure we remove the 
>/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 
>will tell for sure.
>Signed-off-by: Chris Lalancette <clalance@xxxxxxxxxx>
>Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.