Work flow of a VM request inside openstack

1. A client enters the user credentials via Horizon, which makes the REST call to Keystone for authentication.


2. The authentication request will be handled by Keystone, which generates and sends back an authentication token. The token will be stored by Keystone, which will be used to authenticate against the rest of the OpenStack components by using APIs.


3. The action of Launch Instance in the dashboard will convert the creation of a new instance request into an API request, which will be sent to the novaapi service.


4. The nova-api service receives the authentication request and sends it for validation and access permission to Keystone.


5. Keystone checks the token and sends an authentication validation, which includes roles and permissions.


6. The nova-api service later creates an initial entry for an instance in the database and contacts the queuing system via an RPC call (rpc.cast). The call request will be sent to nova-scheduler to specify which host ID will run the instance.


7. The nova-scheduler contacts the queue and subscribes the new instance request.


8. The nova-scheduler performs the information gathering process from the database to find out the appropriate host based on its weighting and filtering algorithms.


9. Once a host has been chosen, the nova-scheduler sends back an RPC call (rpc.cast) to start launching an instance that remains in the queue.


10. The nova-compute contacts the queue and picks up the call issued by the nova-scheduler. Therefore, nova-compute proceeds with the subscription on the instance and sends an RPC call (rpc.call) in order to get instance-related information such as the instance characteristics (CPU, RAM, and disk) and the host ID. The RPC call remains in the queue.


11. The nova-conductor contacts the queue and picks up the call.


12. The nova-conductor contacts the queue and subscribes the new instance request. It interrogates the database to get instance information and publish its state in the queue.


13. The nova-compute picks the instance information from the queue and sends an authentication token in a REST call to the glance-api to get a specific image URI from a glance.The image URI will be obtained by the Image ID to find the requested one from the image repository.


14. The glance-api will verify the authentication token with Keystone.


15. Once validated, glance-api returns the image URI, including its metadata, which specifies the location details of the image that is being scrutinized.


16. The nova-compute sends the authentication token to a neutron-server via a REST call to configure the network for the instance.


17. The neutron-server checks the token with Keystone.


18. Once validated, the neutron-server contacts its agents, such as the neutron-l2-agent and neutron-dhcp-agent, by submitting the request in the queue.


19. Neutron agents pick the calls from the queue and reply by sending network information pertaining to the instance. For example, neutron-l2-agent gets the L2 configuration from Libvirt and publishes it in the queue. On the contrary, neutron-dhcp-agent contacts dnsmasq for the IP allocation and returns an IP reply in the queue.


20. The neutron-server collects all the network settings from the queue and records it in the database. Therefore, it sends back an RPC call to the queue along with all the network details.


21. Nova-compute contacts the queue and grabs the instance network configuration.


22. Nova-compute sends the authentication token to cinder-api via a REST call to get the volume, which will be attached to the instance.


23. The cinder-api checks the token with Keystone.


24. Once validated, the cinder-api returns the volume information to the queue.


25. Nova-compute contacts the queue and grabs the block storage information.


26. At this stage, the nova-compute executes a request to the specified hypervisor via Libvirt to start the virtual machine.


27. In order to get the instance state, nova-compute sends an RPC call (rpc.call) to nova-conductor.


28. The nova-conductor picks the call from the queue and replies to the queue by mentioning the new instance state.


29. The polling instance state is always performed via nova-api, which consults the database to get the state information and sends it back to the client.

转载于:https://my.oschina.net/jenningsloy318/blog/716863

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值