​去年分析的一个问题：Openstack: migration 虚拟机热迁移 失败的注意点。里面有很多未知答案的问题。最近再总结一下，可能会有几篇，算是一个系列。

在这两天又遇到，继续看了一下。找到了之前一直没有搞明白的一个问题：refcount到底是被谁占，用没有释放？这里说一下大概。详细的热迁移步骤，请参阅下面两个说明和文档：

https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/libvirt-neutron-sriov-livemigration.html
https://docs.openstack.org/nova/latest//reference/live-migration.html

是在Openstack的新版本里加进来，对有SRIOV设备的虚拟机进行热迁移功能。测试的时候又碰到了这个错误：
Linux: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

这次是没跑了，也算是有机会继续看，继续学习。一开始以为是内核的问题，后来在网上查了很多资料：在Linux内核早期比较老的版本，确实是有几个这种泄漏ref的bug。但是在新版本都已经解决了。中间又看到几个例子是说，私有的内核模块也可能引入这个问题。

经过认真分析，明确了，自己产品里的一个内核模块是会将net_device的refcount的值hold一下，因为要用net_device的指针。调用的接口是：dev_get_by_name。这个函数就非常的具有滑稽性，如果调用，而且可以找到相应的设备，就会dev_hold设备；如果调用者不想hold，要单独执行dev_put，这就形成字面意义的不对称，dev_get_by_name和dev_put，明眼看就不是一对。所以要有意识，在调用了dev_get_by_name之后，要仔细考虑是否真的需要hold dev，如果不需要，要记得dev_put一下。当然本文要说的问题不是出在这里。

问题是在live-migration的过程中nova的调用链里，会将原有instance的设备detach掉，在detach的时候，没有设置udev规则来删除这个内核模块，导致这个内核模块对net_device一直有占用refcount，从而产生这个错误日志。

这里的一个问题，在做detach的时候，内核具体会做哪些操作？