nova-compute源码结构分析

一 目录结构

Compute服务位于nova/compute

[[email protected] compute]# tree -L 1
.
├── api.py
├── build_results.py
├── cells_api.py
├── claims.py
├── flavors.py
├── __init__.py
├── __init__.pyc
├── instance_actions.py
├── manager.py
├── monitors
├── power_state.py
├── power_state.pyc
├── resource_tracker.py
├── rpcapi.py
├── stats.py
├── task_states.py
├── task_states.pyc
├── utils.py
├── utils.pyc
├── vm_states.py
└── vm_states.pyc

二 跟API相关的三个文件

rpcapi.py

这个文件包含了调用nova-compute服务RPC API的client端代码。该文件简化了client调用rpc api的代码。文件注释说明了该文件的作用。

"""

Client side of the compute RPC API.

"""

举例，nova-scheduler中即引用了该代码

#filter_scheduler.py
from nova.compute import rpcapi as compute_rpcapi
#scheduler在选定了一个计算节点后，通过RPC调用计算节点上的nova-compute服务来创建虚拟机。
            self.compute_rpcapi.run_instance(context,
                    instance=updated_instance,
                    host=weighed_host.obj.host,
                    request_spec=request_spec,
                    filter_properties=filter_properties,
                    requested_networks=requested_networks,
                    injected_files=injected_files,
                    admin_password=admin_password, is_first_time=is_first_time,
                    node=weighed_host.obj.nodename,
                    legacy_bdm_in_spec=legacy_bdm_in_spec)

api.py

compute中的本地调用api。每个服务会有一个api.py文件,这个文件提供了该服务的本地调用api接口。

查看api.py文件可以看到，该文件中的很多实现其实调用了compute的rpcapi.py。例如：

 

   def attach_interface(self, context, instance, network_id, port_id,
                         requested_ip):
        """Use hotplug to add an network adapter to an instance."""
        return self.compute_rpcapi.attach_interface(context,
            instance=instance, network_id=network_id, port_id=port_id,
            requested_ip=requested_ip)

从中可以看出，api.py应该是属于遗留代码(legacy code)，不应该继续使用，保留是为了兼容以前的代码。

manager.py是nova-computer最为核心的代码，所有有关虚拟机生命周期管理的函数都在这个模块中，其中ComputerManager类用于执行接受到的RPC请求。把它理解为RPC调用的服务端。

三 资源管理模块

resource_tracker.py和claim.py实现资源管理。

nova-compute为每一个主机创建一个ResourceTracker类实例来跟踪它的资源。作为Openstack的资源管理器，Resource Tracker负责收集主机上的资源以及将资源的使用情况通知nova-scheduler，作为选择主机的依据。

每个主机上都有很多资源，最初，虚拟机的调度和创建，只关心CPU、内存、磁盘等资源。但是随着虚拟机管理越来越精细，特别是NFV（network Functions Virtualization,网络功能虚拟化）场景下，需要更为精细化的资源控制。但哪些资源需要跟踪刷新，哪些不需要，大家很难达成一致。

于是，社区针对Resource Tracker提供了扩展机制（ERT，Extensible Resource Tracker），每个人可以根据自己的需求创建插件实现特定资源的管理，ERT机制的实现位于resource目录，目前默认只有一个vcpu的实现。

monitors目录是UBS的实现，与ERT一起，它们都是Juno中加入的，但是在kilo中会被删除或替换。

四 参考

https://blog.csdn.net/zhengleiguo/article/details/26885557