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? 4.11+ VRs are systemd enabled and don't reboot after patching which is a major difference between 4.9 and 4.11 systemvms/VRs; to make this work for VMware when the nics come up we use a hack (that has been followed since at least 4.6+) to ping the interfaces/gateways: https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/setup/common.sh#L335 After nic/mac-addresses change/configure, 4.9 and previous VRs used to reboot (i.e. 4.9 and previous VRs on vmware used to reboot twice, once after patching and once more to reconfigure nic-mac assignments). 4.11+ VRs don't do reboots at all but uses udevadm for nic/mac/interface configurations: https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/setup/router.sh#L62 So you may try two tests and see if it makes any difference wrt above mentioned code -- (a) one to increase timeout/ping retries and (b) another to reboot after udev/mac-address configurations (which would only require re-building the systemvm.iso file and scp-ing on the secondary storage in your test environment). Finally, if you can share logs or other details about the test setup and environment, I can help you with some investigations. - Rohit <https://cloudstack.apache.org> ________________________________ From: Rene Moser <m...@renemoser.net> Sent: Tuesday, February 20, 2018 1:46:02 PM To: us...@cloudstack.apache.org; dev@cloudstack.apache.org Subject: [4.11] Management to VR connection issues Hi We upgraded from 4.9 to 4.11. VMware 6.5.0. (Testing environment). VR upgrade went through. But we noticed that the communication between the management server and the VR are not working properly. We do not yet fully understand the issue, one thing we noted is that the networks configs seems not be bound to the same interfaces after every reboot. As a result, after a reboot you may can connect to the VR by SSH, after another reboot you can't anymore. The Network name eth0 switched from the NIC id 3 to 4 after reboot. The VR is kept in "starting" state, of course as a consequence we get many issues related to this, no VM deployments (kept in starting state), VM expunging failure (cleanup fails), a.s.o. Have anyone experienced similar issues? Regards René rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
