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