Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
From: Simon Weller <sweller@ena.com>
To: "users@cloudstack.apache.org" <users@cloudstack.apache.org>
Subject: Re: Long downtimes for VMs through automatically triggered storage
 migration
Thread-Topic: Long downtimes for VMs through automatically triggered storage
 migration
Thread-Index: AQHSJHZ/ur0ItN0+QkWw8xoPEosJq6Ck1BDk
Date: Wed, 12 Oct 2016 13:47:52 +0000
Message-ID: <SN1PR02MB20160D5AA755D7BF6378EE45A9DD0@SN1PR02MB2016.namprd02.prod.outlook.com>
References: <3bf570f1-6cbb-7fa8-d604-7ebc6aabed89@heinlein-support.de>
In-Reply-To: <3bf570f1-6cbb-7fa8-d604-7ebc6aabed89@heinlein-support.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [107.204.113.98]
x-ms-office365-filtering-correlation-id: f4ca9f24-ddd4-49de-6c78-08d3f2a65d33
x-microsoft-exchange-diagnostics: 
	1;SN1PR02MB2015;6:wfCDbboqnLmP12sWG0k9bIaz9X/YanNesswftNVAA+OPRioJOMDRXjjocO8PR8sN7u1qgUbKxL9335klru4S8SGwmD3Zy6FenTIuFtx8tg5tV4myspb1IEcU8VL1GR5WLN9iktjjRWRDzmDqHP+cEPDjsDEs64ueRykWeEuUX7X3KTsNsIxRTsHyvOGV+DImKVvpaRRJ7mlcjmAvcA/pjp/ooOvv24Pm+kYsVQFKJLuPD+I4+KtETBYFEjeiFqWPajcudv9EUdLJrxyhvz948fTyZz98FNn06p7ZThn/MfOkB0sauMhDltKOdy5xRyhn;5:P1PPX8W27ogSh8/xD5nrtC5iZWK8BqPIiCYxGXMOGn8v16B3/Wgx8/NycHA31R4nnWiux/A3RoeE8QB7YtdCUKQZd+18uyiCs6hGtl2B1MJFl3K/axIbO25fXysE1QfX1SYrIS/4IWJew4ron9nmwg==;24:IR9CnW1wsAr5onkxovIulhmr+NDEZq+Ds+sB+Tw8MEVpSKCgFxKZChZQW8KykJ5kGeUeeYBBBur0cLBKUfqfrG4e4/IuuFufj5Rk5CgvQ+s=;7:8DyapRTkBuSxdp38BuAlxlUFNV3H6aiO48qQC0NES7c9M5kOHyOXUnonfCFEkEJjzmJD/OxrzLe6iw/UzV5nNIpXI2cP/0QM4MKoEZqTDg1tgtnBmjA1X/lFpBjgDKa1hyLOUrnM8rigu3d8LoIjRifk80GGAjL1tSigrFN8NyzuW97ozIe9jo3+zXRXPna5ZzBPbQF/B45lzmIEDFxErjwwbwgNz3mqcS1wKBlaqQCyCPqVQZ8eJjoOkkAPFZ30hgHn8qC5PdZTlnd+KyUJ9idjAp+A3GnzfiIjtfRrWAAaYK+v04YeETormCVjc7OJPXlgjVZXjlqBF9wrWDK/MJ3DB/9DRtPuxScAc2PLitI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR02MB2015;
x-microsoft-antispam-prvs: <SN1PR02MB201587078D87A6706E850BE2A9DD0@SN1PR02MB2015.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:SN1PR02MB2015;BCL:0;PCL:0;RULEID:;SRVR:SN1PR02MB2015;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(7916002)(189002)(53754006)(199003)(377454003)(189998001)(3280700002)(7846002)(50986999)(3900700001)(92566002)(8936002)(5660300001)(15974865002)(106116001)(19617315012)(10400500002)(2900100001)(3660700001)(54356999)(7696004)(97736004)(19627405001)(16236675004)(110136003)(81166006)(19625215002)(68736007)(107886002)(33656002)(9686002)(76176999)(19580405001)(11100500001)(19580395003)(586003)(5002640100001)(106356001)(2906002)(105586002)(99286002)(6116002)(15975445007)(86362001)(6916009)(2501003)(122556002)(3846002)(101416001)(6606003)(2351001)(66066001)(2950100002)(102836003)(76576001)(16601075003)(87936001)(1730700003)(7736002)(7906003)(81156014)(74316002)(77096005)(8676002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR02MB2015;H:SN1PR02MB2016.namprd02.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
received-spf: None (protection.outlook.com: ena.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_SN1PR02MB20160D5AA755D7BF6378EE45A9DD0SN1PR02MB2016namp_"
MIME-Version: 1.0
X-OriginatorOrg: ena.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 13:47:52.9084
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6dc38cd4-4d4f-4826-9649-17854289d170
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB2015
X-ENA-MailScanner-Information: Please contact support@ena.com for more information
X-ENA-MailScanner-ID: A112A1480765.AD773
X-ENA-MailScanner: No viruses found
X-ENA-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.5,
	required 4, BAYES_00 -3.20, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.20, HTML_MESSAGE 1.20, OS_UNKNOWN -0.10,
	SPF_HELO_PASS -0.20)
X-ENA-MailScanner-From: sweller@ena.com
X-ENA-MailScanner-Watermark: 1476884876.57977@L2XCS6tDgCMZQFJi10YroA
archived-at: Wed, 12 Oct 2016 13:48:19 -0000

--_000_SN1PR02MB20160D5AA755D7BF6378EE45A9DD0SN1PR02MB2016namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Melanie,


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).
There is a global configuration item for preventing CloudStack from attempt=
ing to automatically migrate across primary storage arrays. It's called ena=
ble.ha.storage.migration.
If you set this to false, it will prevent an attempted storage migration on=
 HA.

- Si

________________________________
From: Melanie Desaive <m.desaive@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 mig=
ration

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

--
--

Heinlein Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Linux: Support, Consulting, Kurs, Training, Schulung ...<http://www.heinlei=
n-support.de/>
www.heinlein-support.de
Wir bieten Wissen und Erfahrung ...und Sie k=F6nnen sich aussuchen, wie Sie=
 beides nutzen. Profitieren Sie vom Wissen in unseren Linux-Schulungen an u=
nserer Akademie ...


Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. =A735a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Gesch=E4ftsf=FChrer: Peer Heinlein  -- Sitz: Berlin

--_000_SN1PR02MB20160D5AA755D7BF6378EE45A9DD0SN1PR02MB2016namp_--