本文主要是介绍Openstack: live-migration SRIOV的一个问题（1），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
去年分析的一个问题：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的时候，内核具体会做哪些操作？
这篇关于Openstack: live-migration SRIOV的一个问题（1）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
