Hi Simon, thanks for your swift answer!
Am 12.10.2016 um 15:47 schrieb Simon Weller: > So if I understand correctly here, you have 2 clusters within a pod and > you're using cluster level storage (meaning each cluster has it's own primary > storage). You are perfectly right. > There is a global configuration item for preventing CloudStack from > attempting to automatically migrate across primary storage arrays. It's > called enable.ha.storage.migration. > If you set this to false, it will prevent an attempted storage migration on > HA. The enable.ha.storage.migration setting really looks like a quick fix for our problem. Great. What we are still thinking about is the point, if it is principally a good idea to limit CloudStack in its ability to freely and automatically migrate VMs between all cluster nodes. Is setting "enable.ha.storage.migration"=false the intended way to handle a setup with multiple clusters or is it kind of a dirty hack to circumvent disadvantages of our setup? In the latter case we would like to know that and keep a focus on alternatives and be ready to improve our setup in the mid-term. We would be happy to hear about additional advice, experience and suggestions. Thanks a lot, Melanie Desaive -- -- Heinlein Support GmbH Linux: Akademie - Support - Hosting http://www.heinlein-support.de Tel: 030 / 40 50 51 - 0 Fax: 030 / 40 50 51 - 19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin > ________________________________ > From: Melanie Desaive <m.desa...@heinlein-support.de> > Sent: Wednesday, October 12, 2016 5:50 AM > To: users@cloudstack.apache.org > Subject: Long downtimes for VMs through automatically triggered storage > migration > > Hi all, > > my college and I are having a dispute on when cloudstack should > automatically trigger storage migrations and what options we have to > control cloudstacks behavior in terms of storage migrations. > > We are operating a setup with two XenServer clusters which are combined > into one pod. Each cluster with its own independent SRs of type lvmoiscsi. > > Unfortunately we had a XenServer bug, which prevented a few VMs to start > on any compute node. Any time this bug appeared, CloudStack tried to > start the concerned VM successively on each node of the actual cluster > and afterwards started a storage migration to the second cluster. > > We are using UserDispersing deployment planner. > > The decision of the deployment planner to start the storage migration > was very unfortunate for us. Mainly because: > * We are operating some VMs with big data volumes which where > inaccessible for the time the storage migration was running. > * The SR on the destination cluster did not even have the capacity to > take all volumes of the big VMs. Still the migration was triggered. > > We would like to have some kind of best practice advice on how other are > preventing long, unplanned downtimes for VMs with huge data volumes > through automated storage migration. > > We discussed the topic and came up with the following questions: > * Is the described behaviour of the deployment planner intentional? > * Is it possible to prevent some few VMs with huge storage volumes from > automated storage migration and what would be the best way to achieve > this? Could we use storage or host tags for this purpose? > * Is it possible to globally prevent the deployment planner from > starting storage migrations? > * Are there global settings to achieve this? > * Would we have to adapt the deployment planner? > * Do we have to rethink our system architecture and avoid huge data > volumes completely? > * Was the decision to put two clusters into one pod a bad idea? > * Are there other solutions to our problem? > > We would greatly appreciate any advice in the issue! > > Best regards, > > Melanie > > --
