This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • System VMs and services resiliency
Skip to end of metadata
Go to start of metadata

Virtual Router:


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.



Services (daemons) in Virtual router:

The below are the list of services which are running on the VR.

  1. sshd
  2. dnsqmasq
  3. password server
  4. haproxy
  5. webserver (apache webserver)
  6. ntpd
  7. crond
  8. rpcbind
  9. acpid
  10. udev


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.

  1. sshd
  2. ntpd
  3. crond
  4. rpcbind
  5. acpid
  6. udev
  7. password server – It internal starts socat process. When socat dies password server starts it again.

The list of services whose config files updated and restarted by cloudstack:

  1. haproxy – for load balancing configuration
  2. dnsmasq – for dhcp and dns entries configuration
  3. webserver – as of know when multiple ip ranges added

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

About Monitoring services:

  1. VR monitoring can only monitor the services, which are running on VR.
  2. Monitoring can help to start a service, which got crashed due to unexpected reason.


          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.


  • No labels