Re: [Xen-devel] [PATCH] blktap2: add blktap2 device classanddevicecontroller

[Ryan O'Connor <rjo@xxxxxxxxx>]

Hi Kan,

On Wed, Jul 01, 2009 at 04:41:10PM +0900, Masaki Kanno wrote:
> Hi Ryan,
> 
> I tested your patch by using a PV domain. 
> The results are as follows.
> 
> Managed domains|Domain status |Commands        |tap:aio |tap:sync
> ---------------+--------------+----------------+--------+--------
> Yes            |Active        |xm block-attach | OK     | OK
>                |              +----------------+--------+--------
>                |              |xm block-deatch | OK     |Failed-1
>                |              +----------------+--------+--------
>                |              |xm shutdown     | OK     | OK
>                +--------------+----------------+--------+--------
>                |Inactive      |xm start        | OK     | OK
>                |              +----------------+--------+--------
>                |              |xm block-attach | OK     | OK?-2
>                |              +--------------- +--------+--------
>                |              |xm block-detach | OK     | OK?-2
> ---------------+--------------+----------------+--------+--------
> No             | -            |xm create       | OK     | OK
>                |              +----------------+--------+--------
>                |              |xm block-attach | OK     | OK
>                |              +--------------- +--------+--------
>                |              |xm block-detach | OK     | OK
>                |              +----------------+--------+--------
>                |              |xm shutdown     | OK     | OK
> ---------------+--------------+----------------+--------+--------

Thanks for testing my patch!

> 
> Failed-1:
> xm block-detach command succeeded.
> But I detected the following error message in xend.log.
> 
> [2009-07-01 16:12:30 3618] DEBUG (XendDomainInfo:1190) 
> XendDomainInfo.destroyDevice: deviceClass = tap, device = 833
> [2009-07-01 16:12:30 3618] DEBUG (DevController:180) Waiting for 833 - 
> destroyDevice.
> [2009-07-01 16:12:31 3618] DEBUG (DevController:649) deviceDestroyCallback 
> /local/domain/0/backend/tap/8/833/hotplug-status.
> [2009-07-01 16:12:31 3618] DEBUG (DevController:649) deviceDestroyCallback 
> /local/domain/0/backend/tap/8/833/hotplug-status.
> [2009-07-01 16:12:31 3618] DEBUG (DevController:658) deviceDestroyCallback 6.
> [2009-07-01 16:12:31 3618] ERROR (XendConfig:1129) dumping sxp from device 
> controllers
> Traceback (most recent call last):
>   File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 1115, 
> in to_sxp
>     configs = controller.configurations(txn)
>   File "usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", 
> line 242, in configurations
>     return map(lambda x: self.configuration(x, transaction), 
> self.deviceIDs(transaction))
>   File "usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", 
> line 242, in <lambda>
>     return map(lambda x: self.configuration(x, transaction), 
> self.deviceIDs(transaction))
>   File "usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", 
> line 249, in configuration
>     configDict = self.getDeviceConfiguration(devid, transaction)
>   File "usr/lib/python2.4/site-packages/xen/xend/server/blkif.py", line 160, 
> in getDeviceConfiguration
>     \047bootable\047)
>   File "usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", 
> line 447, in readBackendTxn
>     raise VmError("Device %s not connected" % devid)
> VmError: Device 833 not connected

I have been able to reproduce this, although sometimes the block-detach
works without error. Further, I also get a similar error without my
patch when detaching a vbd device from a running managed domain:

[2009-07-01 12:47:00 17306] DEBUG (XendDomainInfo:1187) 
XendDomainInfo.destroyDevice: deviceClass = vbd, device = 51713
[2009-07-01 12:47:00 17306] DEBUG (DevController:180) Waiting for 51713 - 
destroyDevice.
[2009-07-01 12:47:00 17306] DEBUG (DevController:678) deviceDestroyCallback 
/local/domain/0/backend/vbd/13/51713/hotplug-status.
[2009-07-01 12:47:00 17306] DEBUG (DevController:678) deviceDestroyCallback 
/local/domain/0/backend/vbd/13/51713/hotplug-status.
[2009-07-01 12:47:00 17306] DEBUG (DevController:687) deviceDestroyCallback 6.
[2009-07-01 12:47:00 17306] ERROR (XendConfig:1129) dumping sxp from device 
controllers
Traceback (most recent call last):
  File "usr/lib/python2.5/site-packages/xen/xend/XendConfig.py", line 1119, in 
to_sxp
    dev_type, dev_cfg = self['devices'][dev_uuid]
KeyError: None

This looks to be a race condition between the block device detach and
the managed_domain_save() code. The device is partially removed from
xenstore when to_sxp() builds the device sxprs, so to_sxp() tries to
collect information on a device that is being removed.

> OK?-2:
> The deivce class is 'tap2'.  Ideally, the device class should be 'tap'.
> Could you confirm information of xm list --long?

Yes, you are correct that the device shows up as 'tap2' before the
domain is created. This is because it is not known if the device will be
a blktap1 or blktap2 device until we call Blktap2Controller.createDevice().
However, since the domain is inactive and the devices have not been
created we do not need to know the 'actual' device class as there are no
entries in xenstore to remove. All deviceRemove does at that point is
remove the entry from the domain's config sxpr.

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

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