[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |