Hey Rene. Can you check that OS type that has been applied to your system VM template. I found that mine were coming up as 32bit Debian 5, making them go REALLY slow and if there are rules applied to the firewall it takes forever to provision. Switching the guest OS fixed it.
If you use Linux (other 64) - which is guestos_id 99 they run properly I suspect that the VMware 6.5 mappings are failing when they aren't supported by the 6.0 SDK which we use, but I'll need to get that verified.... I think that we should have a 'ACS SystemVM' guest OS, which we can map to the best performing guest OS for each hypervisor version. paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -----Original Message----- From: Rene Moser [mailto:m...@renemoser.net] Sent: 22 February 2018 16:27 To: us...@cloudstack.apache.org; dev@cloudstack.apache.org Subject: Re: [4.11] Management to VR connection issues On 02/20/2018 08:04 PM, Rohit Yadav wrote: > Hi Rene, > > > Thanks for sharing - I've not seen this in test/production environment yet. > Does it help to destroy the VR and check if the issue persists? Also, is this > behaviour system-wide for every VR, or VRs of specific networks or topologies > such as VPCs? Are these VRs redundant in nature? We have non-redundant VRs, and we haven't looked at VPC routers yet. The current analyses shows the following: 1. Started the process to upgrade an existing router. 2. Router gets destroyed and re-deployed with new template 4.11 as expected. 3. Router OS has started, ACS router state keeps "starting". When we login by console, we see some actions in the cloud.log. At this point, router will be left in this state and gets destroyed after job timeout. 4. We reboot manually on the OS level. VR gets rebooted. 5. After the OS has booted, ACS Router state switches to "Running" 6. We can login by ssh. however ACS router still shows "requires upgrade" (but the OS has already booted with template 4.11) 7. When we upgrade, the same process happens again points 1-3. Feels like a dead lock. Logs: https://transfer.sh/DdTtH/management-server.log.gz We continue our investigations Regards René
