cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Southam <>
Subject Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Date Thu, 04 Jun 2015 15:08:35 GMT

On 04 Jun 2015, at 16:50, Koushik Das <<>>

Thanks for the clarification Daan. So as I understand - after VR reboot outside of CS if there
is any config differences (between persisted ones and DB) then MS will immediately push the
config from DB to VR. Is that correct?
Is there any document/write-up available for the persistence changes?


I cannot find the docs we wrote up but will send the link when I do!

Essentially the shell commands are replaced with json which is passed to VPCr or VR.  The
son object is then merged into a son configuration on the router.  There is one config per
type (firewallacls, lips, forwarding_rules etc.).  These are stored in /etc/cloudstack.

(See ./core/src/com/cloud/agent/resource/virtualnetwork/facade/ and ./core/src/com/cloud/agent/resource/virtualnetwork/model/)

Each time the config is merged, some python runs which compares the configured state to the
expected state from the json files.  It will then provision (or deprovision) anything that
has changed.

(See systemvm/patches/debian/config/opt/cloud/bin/

In addition on reboot (planned or otherwise), the configurator is also called setting the
provisioned state back to the last known good state.

For VPCs we also implemented a redundant VPCr (based upon the same technology as the normal
VR) and, calls to allow an upgrade from single VPCr to redundant VPCr.

Beyond this, cloudstack will work the same as it always did.  If it loses touch with a router,
it will takes steps to recreate it etc.

So yes, the router is no longer truly stateless but, cloudstack remains in charge.  The intention
is not to break the orchestration paradagm.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message