Another reason of slow can be VR configuration(persistent VR configuration design). When one component config apply, whole VR configuration apply is executed. Due to this the VR boot up time will increase.
Thanks, Jayapal > On May 3, 2017, at 1:55 PM, Marc-Aurèle Brothier <ma...@exoscale.ch> wrote: > > Hi Wido, > > Well for us, it's not a version problem, it's simply a design problem. This > VR is very problematic during any upgrade of cloudstack (which I perform > every week almost on our platform), same goes for the secondary storage VMs > which scans all templates. We've planned on our roadmap to get rid of the > system vms. The VR is really a SPoF. > > On Tue, May 2, 2017 at 7:57 PM, Wido den Hollander <w...@widodh.nl> wrote: > >> Hi, >> >> Last night I upgraded a CloudStack 4.5.2 setup to 4.9.2.0. All went well, >> but the VR provisioning is terribly slow which causes all kinds of problems. >> >> The vr_cfg.sh and update_config.py scripts start to run. Restart dnsmasq, >> add metadata, etc. >> >> But for just 1800 hosts this can take up to 2 hours and that causes >> timeouts in the management server and other problems. >> >> 2 hours is just very, very slow. So I am starting to wonder if something >> is wrong here. >> >> Did anybody else see this? >> >> Running Basic Networking with CloudStack 4.9.2.0 >> >> Wido >> DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.