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

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



Fri, 26 Jun 2009 02:33:53 -0700, Ryan O'Connor wrote:

>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.

Hi Ryan,

I also think we need the dedicated blktap2 controller class. 
I'm really looking forward to the patch from you. 

Best regards,
 Kan



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


 


Rackspace

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