Scenario | Action from Cloudstack |
|
|
VR is shutdown outside the cloudstack | Cloudstack bring up it into running state |
|
|
Is VR HA enabled | The default network offerings for the VR is HA enabled |
|
|
What if VR is stopped from the cloudstack | VR will stay in stopped state. It will not change into running state automatically |
|
|
What happens when VR is stopped and VM got deployed in that network | VR will change into running state in the vm deployment process. |
|
|
What happens when VR is destroyed from the cloudstack | Cloudstack will NOT spin up new router automatically |
|
|
Can I destroy a router in the network from the cloudstack | Yes, you can stop and destroy a router of the network |
|
|
What happen If I deploy VM in a network where router is destroyed from cloudstack | Cloudstack spin up new router |
|
|
Running VR destroyed from outside the cloudstack | Cloudstack shows the VR as stopped. Cloudstack FAILs to bring up the router back to running state |
|
|
Here are the scenarios for SSVM/CPVM
1. SSVM/CPVM stopped/destroyed from CS. The VM is restarted/recreated by CS.
2. SSVM/CPVM stopped outside of CS. CS detects VM status as 'Stopped' and agent status as 'Disconnected' and brings them up by starting the VM.
3. The cloud agent is stopped/crashes but VM is still running. CS detects agent status as 'Disconnected'. In this case there is no auto recovery as the VM is still running. Option is to restart the agent service or stop/destroy SSVM and let CS automatically spin it up again
There are also some additional services like web server in SSVM. If it is not running then certain operation related to upload/download of volume gets affected.
The below are the list of services which are running on the VR.
The list of services can’t be restarted during life cycle of VR :
The below are the services which are configure one time (boot time), after that cloudstack will not touch these services.
As there no issues to reported on the below service failures. Monitoring below service will not add any value.
The list of services whose config files updated and restarted by cloudstack:
haproxy: cloudstack configures the haproxy and reboots. Due to misconfiguration haproxy fails. If haproxy failed due config error haproxy
come up with old config and reports error to cloudstack.
Only the below case found where monitoring will help
https://issues.apache.org/jira/browse/CLOUDSTACK-4623
About Monitoring services:
Example:
a. Services crashed due to bugs in the code.
b. OS can killed service when there is out of memory or no cpu cycles for the service.
3. VR monitor can NOT help to restart the service, which failed to due to misconfiguration of the configuration file of the service/daemon.