The VR configurations are not persisted and so these are not present when out of band movement happens outside of CS. When a VR is recreated/rebooted from CS all the configurations are read from DB and pushed to the VR.
The VR was originally designed as a stateless entity, all state/configuration is pushed to it by on start by MS. -----Original Message----- From: Rene Moser [mailto:m...@renemoser.net] Sent: Wednesday, 3 June 2015 20:28 To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not? Sorry for not answering in the thread, I was not on the dev ML so I could not reply I reported this current behavior to be an issue on the user ML and wanted to ask Koushik Das about his experiences. I would not agree, in an Vmware environment live migrations, e.g. Vmware DRS breaks IPtables normally. In my opinion, this would make DRS senseless. And if it happens, it would be uncommon. We do live migrations daily with VMs having IPtables rules and I didn't see such a behaviour on any of these VMs. Could you share more information about your experiences Koushik Das? In what conditions this happend? In any case I would love to test DRS live migraions on VR without this current behavior. In any way, with this current behaviour, we would have a lot of downtimes. The other "solution" would be reapplying the rules without reboot, I am not fully aware of the new behaviour af aggration but wouldn't this also cause a network outage? Yours René
