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

[Xen-devel] Re: [PATCH] xend: Fix vbd/tapdisk device destruction

To: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xend: Fix vbd/tapdisk device destruction
From: Ryan O'Connor <rjo@xxxxxxxxx>
Date: Fri, 26 Jun 2009 02:33:53 -0700
Cc: dmeyer@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, keir.fraser@xxxxxxxxxxxxx
Delivery-date: Fri, 26 Jun 2009 02:36:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <B8C9F48540E3FEkanno.masaki@xxxxxxxxxxxxxx>
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: <B8C9F48540E3FEkanno.masaki@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
Hi Kan,

On Wed, Jun 24, 2009 at 01:35:51PM +0900, Masaki Kanno wrote:
Content-Description: Mail message body
> Hi,
> 
> When I repeated creating and shutting off a guest domain, I detected 
> that processes of tapdisk2 were left.  Then I saw the following error 
> message in xend.log.
<snip> 
> [2009-06-22 14:36:21 3626] DEBUG (XendDomainInfo:2221) Removing vbd/769
> [2009-06-22 14:36:21 3626] DEBUG (XendDomainInfo:1137) 
> XendDomainInfo.destroyDevice: deviceClass = tap, device = vbd/769
> [2009-06-22 14:36:21 3626] ERROR (XendDomainInfo:2228) Device release failed: 
> vm2; tap; vbd/769
> Traceback (most recent call last):
>   File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 
> 2222, in _releaseDevices
>     self.destroyDevice(true_devclass, dev, False);
>   File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 
> 1154, in destroyDevice
>     path = self.getDeviceController(deviceClass).readBackend(dev, 
> \047params\047)
>   File "usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", 
> line 467, in readBackend
>     raise VmError("Device %s not connected" % devid)
> VmError: Device 769 not connected
> 
> 
> This patch solves the problem.  And the patch solves the detected 
> problem by Ryan.

Your attached patch does indeed solve this problem, however it breaks
save/restore for blktap1. Taking a few steps back, I'm not sure
hard-coding the device path to device/vbd is the right way to fix this.
Xend seems to trust that devices in /vm/<uuid>/<deivceClass>/ actually
belong to <devClass>.

I think this points to a bigger problem. Bllktap2 devices need their
own device controller for their entire life-cycle, but xend currently
treats the blktap2 device as a vbd after it is created. As a result we
have blktap2 specific code in DevController, and we switch between using
the vbd and tap controller on the blktap2 device. Further, if we want to
get save/restore working for blktap2 we'll need to add more
blktap2-specific code to xend (to store and retrieve the original
uname).

For these reasons I don't think blktap2's current approach of creating a
vanilla vbd device will work in the long run. Instead I think we need a
dedicated blktap2 controller class. I have a patch that does just this,
which I will post later today after a bit more testing.

Thanks,
Ryan
-- 
 Ryan O'Connor <rjo@xxxxxxxxx>

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