Can someone explain the cluster = =3D policies to me? The explanation at http://www.ovirt.org/Features/Even_VM_Count_Di= =3D stribution is not quite clicking for me.
=3D

HighVMSCount - Maximum VM limit. Exceeding it qualifi= =3D es the host as overloaded. (Understood)
MigrationThreshold&n= bs=3D p;- defines a buffer before we start migrating VMs from the host (Not quite grasping. If my High limit is 5 does this mean that it will= =3D only begin to move VMs when the count reaches 10?)
SPMVMCountGrace= &n=3D bsp;- defines how many slots for VMs should be reserved on SPM hosts= =3D (the SPM host should have less load than others, so this variable defines = =3D how many VM less it should have) (Does this mean that if I ha= =3D ve a host with only 3 VMs the SPM will 3 VMs minus the SpmWmGrace? Or is th= =3D is HighVmCount minus SpmVmGrace count?)

------=3D_Part_9067_281652121.1403821223261-- --===============5067054416768733542== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzkwNjdfMjgxNjUyMTIxLjE0MDM4MjEyMjMyNjEKQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK CkNhbiBzb21lb25lIGV4cGxhaW4gdGhlIGNsdXN0ZXIgcG9saWNpZXMgdG8gbWU/IFRoZSBleHBs YW5hdGlvbiBhdCBodHRwOi8vd3d3Lm92aXJ0Lm9yZy9GZWF0dXJlcy9FdmVuX1ZNX0NvdW50X0Rp c3RyaWJ1dGlvbiBpcyBub3QgcXVpdGUgY2xpY2tpbmcgZm9yIG1lLiAKCgoKICAgICogSGlnaFZN U0NvdW50IC0gTWF4aW11bSBWTSBsaW1pdC4gRXhjZWVkaW5nIGl0IHF1YWxpZmllcyB0aGUgaG9z dCBhcyBvdmVybG9hZGVkLiAoIFVuZGVyc3Rvb2QgKSAKICAgICogTWlncmF0aW9uVGhyZXNob2xk IC0gZGVmaW5lcyBhIGJ1ZmZlciBiZWZvcmUgd2Ugc3RhcnQgbWlncmF0aW5nIFZNcyBmcm9tIHRo ZSBob3N0ICggTm90IHF1aXRlIGdyYXNwaW5nLiBJZiBteSBIaWdoIGxpbWl0IGlzIDUgZG9lcyB0 aGlzIG1lYW4gdGhhdCBpdCB3aWxsIG9ubHkgYmVnaW4gdG8gbW92ZSBWTXMgd2hlbiB0aGUgY291 bnQgcmVhY2hlcyAxMD8gKSAKICAgICogU1BNVk1Db3VudEdyYWNlIC0gZGVmaW5lcyBob3cgbWFu eSBzbG90cyBmb3IgVk1zIHNob3VsZCBiZSByZXNlcnZlZCBvbiBTUE0gaG9zdHMgKHRoZSBTUE0g aG9zdCBzaG91bGQgaGF2ZSBsZXNzIGxvYWQgdGhhbiBvdGhlcnMsIHNvIHRoaXMgdmFyaWFibGUg ZGVmaW5lcyBob3cgbWFueSBWTSBsZXNzIGl0IHNob3VsZCBoYXZlKSAoIERvZXMgdGhpcyBtZWFu IHRoYXQgaWYgSSBoYXZlIGEgaG9zdCB3aXRoIG9ubHkgMyBWTXMgdGhlIFNQTSB3aWxsIDMgVk1z IG1pbnVzIHRoZSBTcG1XbUdyYWNlPyBPciBpcyB0aGlzIEhpZ2hWbUNvdW50IG1pbnVzIFNwbVZt R3JhY2UgY291bnQ/KSAKCgoKLS0tLS0tPV9QYXJ0XzkwNjdfMjgxNjUyMTIxLjE0MDM4MjEyMjMy NjEKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zl ci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0zRCJm b250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlPQpyaWY7IGZv bnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXY+Q2FuIHNvbWVvbmUgZXhwbGFpbiB0 aGUgY2x1c3RlciA9CnBvbGljaWVzIHRvIG1lPyBUaGUgZXhwbGFuYXRpb24gYXQgPGEgaHJlZj0z RCJodHRwOi8vd3d3Lm92aXJ0Lm9yZy9GZWF0dXJlcz0KL0V2ZW5fVk1fQ291bnRfRGlzdHJpYnV0 aW9uIj5odHRwOi8vd3d3Lm92aXJ0Lm9yZy9GZWF0dXJlcy9FdmVuX1ZNX0NvdW50X0RpPQpzdHJp YnV0aW9uPC9hPiBpcyBub3QgcXVpdGUgY2xpY2tpbmcgZm9yIG1lLjxiciBkYXRhLW1jZS1ib2d1 cz0zRCIxIj48L2Rpdj49CjxkaXY+PGJyPjwvZGl2PjxkaXY+PHVsIHN0eWxlPTNEInBhZGRpbmc6 IDBweDsgbWFyZ2luOiAwLjNlbSAwcHggMHB4IDEuNmVtOz0KIGNvbG9yOiAjMmUzNDM2OyBmb250 LWZhbWlseTogJ1NvdXJjZSBTYW5zIFBybycsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRwPQp4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3A9CmFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiAyMHB4OyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbj0KZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw PQphY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQt Y29sb3I6ICNmZmZmZmY7IiBkYXQ9CmEtbWNlLXN0eWxlPTNEInBhZGRpbmc6IDBweDsgbWFyZ2lu OiAwLjNlbSAwcHggMHB4IDEuNmVtOyBjb2xvcjogIzJlMzQzNjsgZj0Kb250LWZhbWlseTogJ1Nv dXJjZSBTYW5zIFBybycsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTog bm9yPQptYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW49CmUtaGVpZ2h0OiAyMHB4OyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cj0KYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpPQp0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6ICNmZmZm ZmY7Ij48bGkgc3R5bGU9M0QibGluZS1oZWk9CmdodDogMjBweDsiIGRhdGEtbWNlLXN0eWxlPTNE ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PGIgc3R5bGU9M0QiZm9udC13ZWlnaHQ6ID0KNjAwOyIgZGF0 YS1tY2Utc3R5bGU9M0QiZm9udC13ZWlnaHQ6IDYwMDsiPkhpZ2hWTVNDb3VudDwvYj48c3BhbiBj bGFzcz0zRCJBPQpwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPi0gTWF4aW11bSBW TSBsaW1pdC4gRXhjZWVkaW5nIGl0IHF1YWxpZmk9CmVzIHRoZSBob3N0IGFzIG92ZXJsb2FkZWQu ICg8c3Ryb25nPlVuZGVyc3Rvb2Q8L3N0cm9uZz4pPC9saT48bGkgc3R5bGU9M0QibD0KaW5lLWhl aWdodDogMjBweDsgbWFyZ2luLXRvcDogMTBweDsiIGRhdGEtbWNlLXN0eWxlPTNEImxpbmUtaGVp Z2h0OiAyMHB4OyBtPQphcmdpbi10b3A6IDEwcHg7Ij48YiBzdHlsZT0zRCJmb250LXdlaWdodDog NjAwOyIgZGF0YS1tY2Utc3R5bGU9M0QiZm9udC13ZWk9CmdodDogNjAwOyI+TWlncmF0aW9uVGhy ZXNob2xkPC9iPjxzcGFuIGNsYXNzPTNEIkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5icz0KcDs8 L3NwYW4+LSBkZWZpbmVzIGEgYnVmZmVyIGJlZm9yZSB3ZSBzdGFydCBtaWdyYXRpbmcgVk1zIGZy b20gdGhlIGhvc3QgKDxzPQp0cm9uZz5Ob3QgcXVpdGUgZ3Jhc3BpbmcuIElmIG15IEhpZ2ggbGlt aXQgaXMgNSBkb2VzIHRoaXMgbWVhbiB0aGF0IGl0IHdpbGw9CiBvbmx5IGJlZ2luIHRvIG1vdmUg Vk1zIHdoZW4gdGhlIGNvdW50IHJlYWNoZXMgMTA/PC9zdHJvbmc+KTwvbGk+PGxpIHN0eWxlPQo9 M0QibGluZS1oZWlnaHQ6IDIwcHg7IG1hcmdpbi10b3A6IDEwcHg7IiBkYXRhLW1jZS1zdHlsZT0z RCJsaW5lLWhlaWdodDogMjA9CnB4OyBtYXJnaW4tdG9wOiAxMHB4OyI+PGIgc3R5bGU9M0QiZm9u dC13ZWlnaHQ6IDYwMDsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbj0KdC13ZWlnaHQ6IDYwMDsiPlNQ TVZNQ291bnRHcmFjZTwvYj48c3BhbiBjbGFzcz0zRCJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu PQpic3A7PC9zcGFuPi0gZGVmaW5lcyBob3cgbWFueSBzbG90cyBmb3IgVk1zIHNob3VsZCBiZSBy ZXNlcnZlZCBvbiBTUE0gaG9zdHM9CiAodGhlIFNQTSBob3N0IHNob3VsZCBoYXZlIGxlc3MgbG9h ZCB0aGFuIG90aGVycywgc28gdGhpcyB2YXJpYWJsZSBkZWZpbmVzID0KaG93IG1hbnkgVk0gbGVz cyBpdCBzaG91bGQgaGF2ZSkmbmJzcDsgKDxzdHJvbmc+RG9lcyB0aGlzIG1lYW4gdGhhdCBpZiBJ IGhhPQp2ZSBhIGhvc3Qgd2l0aCBvbmx5IDMgVk1zIHRoZSBTUE0gd2lsbCAzIFZNcyBtaW51cyB0 aGUgU3BtV21HcmFjZT8gT3IgaXMgdGg9CmlzIEhpZ2hWbUNvdW50IG1pbnVzIFNwbVZtR3JhY2Ug Y291bnQ/KTwvc3Ryb25nPjwvbGk+PC91bD48L2Rpdj48ZGl2Pjxicj48Lz0KZGl2PjxkaXY+PGJy PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+Ci0tLS0tLT1fUGFydF85MDY3XzI4MTY1MjEyMS4x NDAzODIxMjIzMjYxLS0K --===============5067054416768733542==-- From mjames at media-node.com Fri Jun 27 11:56:40 2014 Content-Type: multipart/mixed; boundary="===============1981962450012319686==" MIME-Version: 1.0 From: Maurice James To: users at ovirt.org Subject: [ovirt-users] Spam Re: Spam Cluster Polcies Date: Fri, 27 Jun 2014 11:56:38 -0400 Message-ID: <95302525.9499.1403884598183.JavaMail.zimbra@media-node.com> In-Reply-To: 673239659.9068.1403821223265.JavaMail.zimbra@media-node.com --===============1981962450012319686== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_9498_745562110.1403884598181 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Can anyone shed any light for me? = ----- Original Message ----- From: "Maurice James" = To: "users" = Sent: Thursday, June 26, 2014 6:20:23 PM = Subject: [ovirt-users] Spam Cluster Polcies = Can someone explain the cluster policies to me? The explanation at http://w= ww.ovirt.org/Features/Even_VM_Count_Distribution is not quite clicking for = me. = * HighVMSCount - Maximum VM limit. Exceeding it qualifies the host as o= verloaded. ( Understood ) = * MigrationThreshold - defines a buffer before we start migrating VMs f= rom the host ( Not quite grasping. If my High limit is 5 does this mean tha= t it will only begin to move VMs when the count reaches 10? ) = * SPMVMCountGrace - defines how many slots for VMs should be reserved o= n SPM hosts (the SPM host should have less load than others, so this variab= le defines how many VM less it should have) ( Does this mean that if I have= a host with only 3 VMs the SPM will 3 VMs minus the SpmWmGrace? Or is this= HighVmCount minus SpmVmGrace count?) = _______________________________________________ = Users mailing list = Users(a)ovirt.org = http://lists.ovirt.org/mailman/listinfo/users = ------=3D_Part_9498_745562110.1403884598181 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable

Can anyone shed any light for me= =3D ?

From: "Maurice James" <mjames(a)media-node.c= om=3D >
To: "users" <users(a)ovirt.org>
Sent: Thursd= ay=3D , June 26, 2014 6:20:23 PM
Subject: [ovirt-users] Spam Clus= =3D ter Polcies

Can someone explain the cluster policies to me? The explan= =3D ation at http://www.ovirt.org/Features/Even_VM_Count_Distributi= =3D on is not quite clicking for me.

HighVMSCount = ;<=3D /span>- Maximum VM limit. Exceeding it qualifies the host as overloaded. (<= =3D strong>Understood)
MigrationThresho= ld=3D - defines a buffer= b=3D efore we start migrating VMs from the host (Not quite grasping. If = =3D my High limit is 5 does this mean that it will only begin to move VMs when = =3D the count reaches 10?)
SPMVMCount= Grac=3D e - defines how man= y =3D slots for VMs should be reserved on SPM hosts (the SPM host should have les= =3D s load than others, so this variable defines how many VM less it should hav= =3D e) (Does this mean that if I have a host with only 3 VMs the = =3D SPM will 3 VMs minus the SpmWmGrace? Or is this HighVmCount minus SpmVmGrac= =3D e count?)

_= =3D ______________________________________________
Users mailing list
Use= =3D rs(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

------=3D_Part_9498_745562110.1403884598181-- --===============1981962450012319686== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0Xzk0OThfNzQ1NTYyMTEwLjE0MDM4ODQ1OTgxODEKQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK CkNhbiBhbnlvbmUgc2hlZCBhbnkgbGlnaHQgZm9yIG1lPyAKLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQoKRnJvbTogIk1hdXJpY2UgSmFtZXMiIDxtamFtZXNAbWVkaWEtbm9kZS5jb20+IApU bzogInVzZXJzIiA8dXNlcnNAb3ZpcnQub3JnPiAKU2VudDogVGh1cnNkYXksIEp1bmUgMjYsIDIw MTQgNjoyMDoyMyBQTSAKU3ViamVjdDogW292aXJ0LXVzZXJzXSBTcGFtIENsdXN0ZXIgUG9sY2ll cyAKCkNhbiBzb21lb25lIGV4cGxhaW4gdGhlIGNsdXN0ZXIgcG9saWNpZXMgdG8gbWU/IFRoZSBl eHBsYW5hdGlvbiBhdCBodHRwOi8vd3d3Lm92aXJ0Lm9yZy9GZWF0dXJlcy9FdmVuX1ZNX0NvdW50 X0Rpc3RyaWJ1dGlvbiBpcyBub3QgcXVpdGUgY2xpY2tpbmcgZm9yIG1lLiAKCgoKICAgICogSGln aFZNU0NvdW50IC0gTWF4aW11bSBWTSBsaW1pdC4gRXhjZWVkaW5nIGl0IHF1YWxpZmllcyB0aGUg aG9zdCBhcyBvdmVybG9hZGVkLiAoIFVuZGVyc3Rvb2QgKSAKICAgICogTWlncmF0aW9uVGhyZXNo b2xkIC0gZGVmaW5lcyBhIGJ1ZmZlciBiZWZvcmUgd2Ugc3RhcnQgbWlncmF0aW5nIFZNcyBmcm9t IHRoZSBob3N0ICggTm90IHF1aXRlIGdyYXNwaW5nLiBJZiBteSBIaWdoIGxpbWl0IGlzIDUgZG9l cyB0aGlzIG1lYW4gdGhhdCBpdCB3aWxsIG9ubHkgYmVnaW4gdG8gbW92ZSBWTXMgd2hlbiB0aGUg Y291bnQgcmVhY2hlcyAxMD8gKSAKICAgICogU1BNVk1Db3VudEdyYWNlIC0gZGVmaW5lcyBob3cg bWFueSBzbG90cyBmb3IgVk1zIHNob3VsZCBiZSByZXNlcnZlZCBvbiBTUE0gaG9zdHMgKHRoZSBT UE0gaG9zdCBzaG91bGQgaGF2ZSBsZXNzIGxvYWQgdGhhbiBvdGhlcnMsIHNvIHRoaXMgdmFyaWFi bGUgZGVmaW5lcyBob3cgbWFueSBWTSBsZXNzIGl0IHNob3VsZCBoYXZlKSAoIERvZXMgdGhpcyBt ZWFuIHRoYXQgaWYgSSBoYXZlIGEgaG9zdCB3aXRoIG9ubHkgMyBWTXMgdGhlIFNQTSB3aWxsIDMg Vk1zIG1pbnVzIHRoZSBTcG1XbUdyYWNlPyBPciBpcyB0aGlzIEhpZ2hWbUNvdW50IG1pbnVzIFNw bVZtR3JhY2UgY291bnQ/KSAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gClVzZXJzIG1haWxpbmcgbGlzdCAKVXNlcnNAb3ZpcnQub3JnIApodHRwOi8v bGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMgCgoKLS0tLS0tPV9QYXJ0Xzk0 OThfNzQ1NTYyMTEwLjE0MDM4ODQ1OTgxODEKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0 bWw+PGJvZHk+PGRpdiBzdHlsZT0zRCJmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcg eW9yaywgdGltZXMsIHNlPQpyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxk aXY+Q2FuIGFueW9uZSBzaGVkIGFueSBsaWdodCBmb3IgbWU9Cj88YnI+PC9kaXY+PGhyIGlkPTNE Inp3Y2hyIj48ZGl2IHN0eWxlPTNEImNvbG9yOiMwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2Zvbj0K dC1zdHlsZTpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1mYW1pbHk6SGVsdmV0aWNh LEFyaWFsLHNhbnMtc2VyaWY7PQpmb250LXNpemU6MTJwdDsiIGRhdGEtbWNlLXN0eWxlPTNEImNv bG9yOiAjMDAwOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXM9CnR5bGU6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogSGVsdmV0aWNhLEFyaWFsLHNhbnMtc2Vy aT0KZjsgZm9udC1zaXplOiAxMnB0OyI+PGI+RnJvbTogPC9iPiJNYXVyaWNlIEphbWVzIiAmbHQ7 bWphbWVzQG1lZGlhLW5vZGUuY29tPQomZ3Q7PGJyPjxiPlRvOiA8L2I+InVzZXJzIiAmbHQ7dXNl cnNAb3ZpcnQub3JnJmd0Ozxicj48Yj5TZW50OiA8L2I+VGh1cnNkYXk9CiwgSnVuZSAyNiwgMjAx NCA2OjIwOjIzIFBNPGJyPjxiPlN1YmplY3Q6IDwvYj5bb3ZpcnQtdXNlcnNdIFNwYW0gJm5ic3A7 Q2x1cz0KdGVyIFBvbGNpZXM8YnI+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0zRCJmb250LWZh bWlseTogdGltZXMgbmV3IHJvbWFuLCBuPQpldyB5b3JrLCB0aW1lcywgc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiIGRhdGEtbWNlLXN0eWxlPTNEImY9Cm9udC1mYW1pbHk6 IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcj0KOiAjMDAwMDAwOyI+PGRpdj5DYW4gc29tZW9uZSBleHBsYWluIHRoZSBjbHVzdGVy IHBvbGljaWVzIHRvIG1lPyBUaGUgZXhwbGFuPQphdGlvbiBhdCA8YSBocmVmPTNEImh0dHA6Ly93 d3cub3ZpcnQub3JnL0ZlYXR1cmVzL0V2ZW5fVk1fQ291bnRfRGlzdHJpYnV0aW89Cm4iIHRhcmdl dD0zRCJfYmxhbmsiIGRhdGEtbWNlLWhyZWY9M0QiaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVy ZXMvRXZlbl9WTT0KX0NvdW50X0Rpc3RyaWJ1dGlvbiI+aHR0cDovL3d3dy5vdmlydC5vcmcvRmVh dHVyZXMvRXZlbl9WTV9Db3VudF9EaXN0cmlidXRpPQpvbjwvYT4gaXMgbm90IHF1aXRlIGNsaWNr aW5nIGZvciBtZS48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48dWwgc3R5bGU9Cj0zRCJw YWRkaW5nOiAwcHg7IG1hcmdpbjogMC4zZW0gMHB4IDBweCAxLjZlbTsgY29sb3I6ICMyZTM0MzY7 IGZvbnQtZmFtaWx5Oj0KICdTb3VyY2UgU2FucyBQcm8nLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12PQphcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDI9CjBw eDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBubz0KbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJvPQprZS13aWR0aDogMHB4OyBiYWNr Z3JvdW5kLWNvbG9yOiAjZmZmZmZmOyIgZGF0YS1tY2Utc3R5bGU9M0QicGFkZGluZzogMHB4OyA9 Cm1hcmdpbjogMC4zZW0gMHB4IDBweCAxLjZlbTsgY29sb3I6ICMyZTM0MzY7IGZvbnQtZmFtaWx5 OiAnU291cmNlIFNhbnMgUHJvJz0KLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvPQpudC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDIwcHg7IG9ycGhhbnM6IGF1 dG89CjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbj0Kb3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFjPQprZ3JvdW5kLWNvbG9y OiAjZmZmZmZmOyI+PGxpIHN0eWxlPTNEImxpbmUtaGVpZ2h0OiAyMHB4OyIgZGF0YS1tY2Utc3R5 bGU9M0Q9CiJsaW5lLWhlaWdodDogMjBweDsiPjxiIHN0eWxlPTNEImZvbnQtd2VpZ2h0OiA2MDA7 IiBkYXRhLW1jZS1zdHlsZT0zRCJmb250LT0Kd2VpZ2h0OiA2MDA7Ij5IaWdoVk1TQ291bnQ8L2I+ PHNwYW4gY2xhc3M9M0QiQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8PQovc3Bhbj4tIE1h eGltdW0gVk0gbGltaXQuIEV4Y2VlZGluZyBpdCBxdWFsaWZpZXMgdGhlIGhvc3QgYXMgb3Zlcmxv YWRlZC4gKDw9CnN0cm9uZz5VbmRlcnN0b29kPC9zdHJvbmc+KTwvbGk+PGxpIHN0eWxlPTNEImxp bmUtaGVpZ2h0OiAyMHB4OyBtYXJnaW4tdG9wOj0KIDEwcHg7IiBkYXRhLW1jZS1zdHlsZT0zRCJs aW5lLWhlaWdodDogMjBweDsgbWFyZ2luLXRvcDogMTBweDsiPjxiIHN0eWxlPTNEPQoiZm9udC13 ZWlnaHQ6IDYwMDsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQtd2VpZ2h0OiA2MDA7Ij5NaWdyYXRp b25UaHJlc2hvbGQ9CjwvYj48c3BhbiBjbGFzcz0zRCJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj4tIGRlZmluZXMgYSBidWZmZXIgYj0KZWZvcmUgd2Ugc3RhcnQgbWlncmF0aW5n IFZNcyBmcm9tIHRoZSBob3N0ICg8c3Ryb25nPk5vdCBxdWl0ZSBncmFzcGluZy4gSWYgPQpteSBI aWdoIGxpbWl0IGlzIDUgZG9lcyB0aGlzIG1lYW4gdGhhdCBpdCB3aWxsIG9ubHkgYmVnaW4gdG8g bW92ZSBWTXMgd2hlbiA9CnRoZSBjb3VudCByZWFjaGVzIDEwPzwvc3Ryb25nPik8L2xpPjxsaSBz dHlsZT0zRCJsaW5lLWhlaWdodDogMjBweDsgbWFyZ2luLT0KdG9wOiAxMHB4OyIgZGF0YS1tY2Ut c3R5bGU9M0QibGluZS1oZWlnaHQ6IDIwcHg7IG1hcmdpbi10b3A6IDEwcHg7Ij48YiBzdHlsPQpl PTNEImZvbnQtd2VpZ2h0OiA2MDA7IiBkYXRhLW1jZS1zdHlsZT0zRCJmb250LXdlaWdodDogNjAw OyI+U1BNVk1Db3VudEdyYWM9CmU8L2I+PHNwYW4gY2xhc3M9M0QiQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+LSBkZWZpbmVzIGhvdyBtYW55ID0Kc2xvdHMgZm9yIFZNcyBzaG91 bGQgYmUgcmVzZXJ2ZWQgb24gU1BNIGhvc3RzICh0aGUgU1BNIGhvc3Qgc2hvdWxkIGhhdmUgbGVz PQpzIGxvYWQgdGhhbiBvdGhlcnMsIHNvIHRoaXMgdmFyaWFibGUgZGVmaW5lcyBob3cgbWFueSBW TSBsZXNzIGl0IHNob3VsZCBoYXY9CmUpJm5ic3A7ICg8c3Ryb25nPkRvZXMgdGhpcyBtZWFuIHRo YXQgaWYgSSBoYXZlIGEgaG9zdCB3aXRoIG9ubHkgMyBWTXMgdGhlID0KU1BNIHdpbGwgMyBWTXMg bWludXMgdGhlIFNwbVdtR3JhY2U/IE9yIGlzIHRoaXMgSGlnaFZtQ291bnQgbWludXMgU3BtVm1H cmFjPQplIGNvdW50Pyk8L3N0cm9uZz48L2xpPjwvdWw+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PC9kaXY+PGJyPl89Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+VXNlcnMgbWFpbGluZyBsaXN0PGJyPlVzZT0KcnNAb3ZpcnQub3Jn PGJyPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj48L2Rp dj48ZGl2PQo+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+Ci0tLS0tLT1fUGFydF85NDk4 Xzc0NTU2MjExMC4xNDAzODg0NTk4MTgxLS0K --===============1981962450012319686==-- From gchaplik at redhat.com Mon Jun 30 07:53:20 2014 Content-Type: multipart/mixed; boundary="===============3436699464513401539==" MIME-Version: 1.0 From: Gilad Chaplik To: users at ovirt.org Subject: Re: [ovirt-users] Spam Cluster Polcies Date: Mon, 30 Jun 2014 07:53:16 -0400 Message-ID: <110367592.881220.1404129196122.JavaMail.zimbra@redhat.com> In-Reply-To: 673239659.9068.1403821223265.JavaMail.zimbra@media-node.com --===============3436699464513401539== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Maurice James" > To: "users" > Sent: Friday, June 27, 2014 1:20:23 AM > Subject: [ovirt-users] Spam Cluster Polcies > = > Can someone explain the cluster policies to me? The explanation at > http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite > clicking for me. > = > = > = > * HighVMSCount - Maximum VM limit. Exceeding it qualifies the host as > overloaded. ( Understood ) minimal #vms on host to enable the module (i.e worst host should have more = than HighVMSCount vms). = > * MigrationThreshold - defines a buffer before we start migrating VMs > from the host ( Not quite grasping. If my High limit is 5 does this m= ean > that it will only begin to move VMs when the count reaches 10? ) don't think that there's any relation with "HighLimit". = It means that migration will happen only if there is a difference of X vms = or more between worst host (source host) to destination host. let say that you have 2 hosts. one has 10 vms and the second 8. if the thre= shold is 3, no migration will happen (10-8 !> 3). > * SPMVMCountGrace - defines how many slots for VMs should be reserved= on > SPM hosts (the SPM host should have less load than others, so this > variable defines how many VM less it should have) ( Does this mean th= at > if I have a host with only 3 VMs the SPM will 3 VMs minus the > SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) you're right, the SPM host will have current + grace VMs in terms of module= calculations. I think that this is problematic, it is likely to be selected as worst host= candidate and that's not the wanted behavior iiuc imo, we should subtract (-) in overloaded hosts and add (+) in underutilize= d. @Jirka? > = > = > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============3436699464513401539==-- From gchaplik at redhat.com Mon Jun 30 07:54:49 2014 Content-Type: multipart/mixed; boundary="===============8641853874596251634==" MIME-Version: 1.0 From: Gilad Chaplik To: users at ovirt.org Subject: Re: [ovirt-users] Spam Re: Spam Cluster Polcies Date: Mon, 30 Jun 2014 07:54:47 -0400 Message-ID: <1320842054.882449.1404129287748.JavaMail.zimbra@redhat.com> In-Reply-To: 95302525.9499.1403884598183.JavaMail.zimbra@media-node.com --===============8641853874596251634== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Answered it the other thread you've opened.. Thanks, = Gilad. ----- Original Message ----- > From: "Maurice James" > To: "users" > Sent: Friday, June 27, 2014 6:56:38 PM > Subject: [ovirt-users] Spam Re: Spam Cluster Polcies > = > Can anyone shed any light for me? > = > From: "Maurice James" > To: "users" > Sent: Thursday, June 26, 2014 6:20:23 PM > Subject: [ovirt-users] Spam Cluster Polcies > = > Can someone explain the cluster policies to me? The explanation at > http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite > clicking for me. > = > = > = > * HighVMSCount - Maximum VM limit. Exceeding it qualifies the host as > overloaded. ( Understood ) > * MigrationThreshold - defines a buffer before we start migrating VMs > from the host ( Not quite grasping. If my High limit is 5 does this m= ean > that it will only begin to move VMs when the count reaches 10? ) > * SPMVMCountGrace - defines how many slots for VMs should be reserved= on > SPM hosts (the SPM host should have less load than others, so this > variable defines how many VM less it should have) ( Does this mean th= at > if I have a host with only 3 VMs the SPM will 3 VMs minus the > SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) > = > = > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > = > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============8641853874596251634==-- From jmoskovc at redhat.com Mon Jun 30 08:57:33 2014 Content-Type: multipart/mixed; boundary="===============8972206856930001881==" MIME-Version: 1.0 From: Jiri Moskovcak To: users at ovirt.org Subject: Re: [ovirt-users] Spam Cluster Polcies Date: Mon, 30 Jun 2014 14:57:29 +0200 Message-ID: <53B15EB9.5010603@redhat.com> In-Reply-To: 110367592.881220.1404129196122.JavaMail.zimbra@redhat.com --===============8972206856930001881== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 06/30/2014 01:53 PM, Gilad Chaplik wrote: > ----- Original Message ----- >> From: "Maurice James" >> To: "users" >> Sent: Friday, June 27, 2014 1:20:23 AM >> Subject: [ovirt-users] Spam Cluster Polcies >> >> Can someone explain the cluster policies to me? The explanation at >> http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite >> clicking for me. >> >> >> >> * HighVMSCount - Maximum VM limit. Exceeding it qualifies the host = as >> overloaded. ( Understood ) > > minimal #vms on host to enable the module (i.e worst host should have mor= e than HighVMSCount vms). > >> * MigrationThreshold - defines a buffer before we start migrating V= Ms >> from the host ( Not quite grasping. If my High limit is 5 does this= mean >> that it will only begin to move VMs when the count reaches 10? ) > > don't think that there's any relation with "HighLimit". > It means that migration will happen only if there is a difference of X vm= s or more between worst host (source host) to destination host. > > let say that you have 2 hosts. one has 10 vms and the second 8. if the th= reshold is 3, no migration will happen (10-8 !> 3). - exactly > >> * SPMVMCountGrace - defines how many slots for VMs should be reserv= ed on >> SPM hosts (the SPM host should have less load than others, so this >> variable defines how many VM less it should have) ( Does this mean = that >> if I have a host with only 3 VMs the SPM will 3 VMs minus the >> SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) > > you're right, the SPM host will have current + grace VMs in terms of modu= le calculations. > I think that this is problematic, it is likely to be selected as worst ho= st candidate and that's not the wanted behavior iiuc > imo, we should subtract (-) in overloaded hosts and add (+) in underutili= zed. - I think it's correct as it is, if the SpmVmGrace+currentVms > = HighVmCount it is overutilized and should be freed if possible. --J > > @Jirka? > >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> --===============8972206856930001881==-- From gchaplik at redhat.com Mon Jun 30 09:11:46 2014 Content-Type: multipart/mixed; boundary="===============6055317511680381944==" MIME-Version: 1.0 From: Gilad Chaplik To: users at ovirt.org Subject: Re: [ovirt-users] Spam Cluster Polcies Date: Mon, 30 Jun 2014 09:11:42 -0400 Message-ID: <1272264898.938258.1404133902629.JavaMail.zimbra@redhat.com> In-Reply-To: 53B15EB9.5010603@redhat.com --===============6055317511680381944== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Jiri Moskovcak" > To: "Gilad Chaplik" , "Maurice James" > Cc: "users" > Sent: Monday, June 30, 2014 3:57:29 PM > Subject: Re: [ovirt-users] Spam Cluster Polcies > = > On 06/30/2014 01:53 PM, Gilad Chaplik wrote: > > ----- Original Message ----- > >> From: "Maurice James" > >> To: "users" > >> Sent: Friday, June 27, 2014 1:20:23 AM > >> Subject: [ovirt-users] Spam Cluster Polcies > >> > >> Can someone explain the cluster policies to me? The explanation at > >> http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite > >> clicking for me. > >> > >> > >> > >> * HighVMSCount - Maximum VM limit. Exceeding it qualifies the hos= t as > >> overloaded. ( Understood ) > > > > minimal #vms on host to enable the module (i.e worst host should have m= ore > > than HighVMSCount vms). > > > >> * MigrationThreshold - defines a buffer before we start migrating= VMs > >> from the host ( Not quite grasping. If my High limit is 5 does th= is > >> mean > >> that it will only begin to move VMs when the count reaches 10? ) > > > > don't think that there's any relation with "HighLimit". > > It means that migration will happen only if there is a difference of X = vms > > or more between worst host (source host) to destination host. > > > > let say that you have 2 hosts. one has 10 vms and the second 8. if the > > threshold is 3, no migration will happen (10-8 !> 3). > = > - exactly > = > > > >> * SPMVMCountGrace - defines how many slots for VMs should be rese= rved > >> on > >> SPM hosts (the SPM host should have less load than others, so this > >> variable defines how many VM less it should have) ( Does this mean > >> that > >> if I have a host with only 3 VMs the SPM will 3 VMs minus the > >> SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) > > > > you're right, the SPM host will have current + grace VMs in terms of mo= dule > > calculations. > > I think that this is problematic, it is likely to be selected as worst = host > > candidate and that's not the wanted behavior iiuc > > imo, we should subtract (-) in overloaded hosts and add (+) in > > underutilized. > = > - I think it's correct as it is, if the SpmVmGrace+currentVms > > HighVmCount it is overutilized and should be freed if possible. not sure I understand, let's take an example 2 hosts: spm: 8 #vms, hsm: 8 #vms. = SPMVMCountGrace =3D 2. in this case the 'worst' host will be the SPM... shouldn't we deduct 2 from= spm and not add? we want less noise there. > = > --J > = > > > > @Jirka? > > > >> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > = >=20 --===============6055317511680381944==-- From jmoskovc at redhat.com Mon Jun 30 09:19:09 2014 Content-Type: multipart/mixed; boundary="===============7513407982287960046==" MIME-Version: 1.0 From: Jiri Moskovcak To: users at ovirt.org Subject: Re: [ovirt-users] Spam Cluster Polcies Date: Mon, 30 Jun 2014 15:19:06 +0200 Message-ID: <53B163CA.40100@redhat.com> In-Reply-To: 1272264898.938258.1404133902629.JavaMail.zimbra@redhat.com --===============7513407982287960046== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 06/30/2014 03:11 PM, Gilad Chaplik wrote: > ----- Original Message ----- >> From: "Jiri Moskovcak" >> To: "Gilad Chaplik" , "Maurice James" >> Cc: "users" >> Sent: Monday, June 30, 2014 3:57:29 PM >> Subject: Re: [ovirt-users] Spam Cluster Polcies >> >> On 06/30/2014 01:53 PM, Gilad Chaplik wrote: >>> ----- Original Message ----- >>>> From: "Maurice James" >>>> To: "users" >>>> Sent: Friday, June 27, 2014 1:20:23 AM >>>> Subject: [ovirt-users] Spam Cluster Polcies >>>> >>>> Can someone explain the cluster policies to me? The explanation at >>>> http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite >>>> clicking for me. >>>> >>>> >>>> >>>> * HighVMSCount - Maximum VM limit. Exceeding it qualifies the ho= st as >>>> overloaded. ( Understood ) >>> >>> minimal #vms on host to enable the module (i.e worst host should have m= ore >>> than HighVMSCount vms). >>> >>>> * MigrationThreshold - defines a buffer before we start migratin= g VMs >>>> from the host ( Not quite grasping. If my High limit is 5 does t= his >>>> mean >>>> that it will only begin to move VMs when the count reaches 10? ) >>> >>> don't think that there's any relation with "HighLimit". >>> It means that migration will happen only if there is a difference of X = vms >>> or more between worst host (source host) to destination host. >>> >>> let say that you have 2 hosts. one has 10 vms and the second 8. if the >>> threshold is 3, no migration will happen (10-8 !> 3). >> >> - exactly >> >>> >>>> * SPMVMCountGrace - defines how many slots for VMs should be res= erved >>>> on >>>> SPM hosts (the SPM host should have less load than others, so th= is >>>> variable defines how many VM less it should have) ( Does this me= an >>>> that >>>> if I have a host with only 3 VMs the SPM will 3 VMs minus the >>>> SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) >>> >>> you're right, the SPM host will have current + grace VMs in terms of mo= dule >>> calculations. >>> I think that this is problematic, it is likely to be selected as worst = host >>> candidate and that's not the wanted behavior iiuc >>> imo, we should subtract (-) in overloaded hosts and add (+) in >>> underutilized. >> >> - I think it's correct as it is, if the SpmVmGrace+currentVms > >> HighVmCount it is overutilized and should be freed if possible. > > not sure I understand, let's take an example > 2 hosts: spm: 8 #vms, hsm: 8 #vms. > SPMVMCountGrace =3D 2. > in this case the 'worst' host will be the SPM... shouldn't we deduct 2 fr= om spm and not add? we want less noise there. > - that's correct, the SPM will be marked as overutilized and the engine = will try to find a host to migrate some vms from the SPM. The SpmGrace = is not about lowering the noise it's about keeping the host less = utilized by running less VMs on it (which will also lower the noise, = because it will give the SPM host worse score when looking for target to = migrate to) --J >> >> --J >> >>> >>> @Jirka? >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >> >> --===============7513407982287960046==-- From gchaplik at redhat.com Mon Jun 30 09:20:33 2014 Content-Type: multipart/mixed; boundary="===============8580440294044746291==" MIME-Version: 1.0 From: Gilad Chaplik To: users at ovirt.org Subject: Re: [ovirt-users] Spam Cluster Polcies Date: Mon, 30 Jun 2014 09:20:31 -0400 Message-ID: <1198533102.949114.1404134431296.JavaMail.zimbra@redhat.com> In-Reply-To: 53B163CA.40100@redhat.com --===============8580440294044746291== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Jiri Moskovcak" > To: "Gilad Chaplik" > Cc: "Maurice James" , "users" > Sent: Monday, June 30, 2014 4:19:06 PM > Subject: Re: [ovirt-users] Spam Cluster Polcies > = > On 06/30/2014 03:11 PM, Gilad Chaplik wrote: > > ----- Original Message ----- > >> From: "Jiri Moskovcak" > >> To: "Gilad Chaplik" , "Maurice James" > >> > >> Cc: "users" > >> Sent: Monday, June 30, 2014 3:57:29 PM > >> Subject: Re: [ovirt-users] Spam Cluster Polcies > >> > >> On 06/30/2014 01:53 PM, Gilad Chaplik wrote: > >>> ----- Original Message ----- > >>>> From: "Maurice James" > >>>> To: "users" > >>>> Sent: Friday, June 27, 2014 1:20:23 AM > >>>> Subject: [ovirt-users] Spam Cluster Polcies > >>>> > >>>> Can someone explain the cluster policies to me? The explanation at > >>>> http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite > >>>> clicking for me. > >>>> > >>>> > >>>> > >>>> * HighVMSCount - Maximum VM limit. Exceeding it qualifies the = host > >>>> as > >>>> overloaded. ( Understood ) > >>> > >>> minimal #vms on host to enable the module (i.e worst host should have > >>> more > >>> than HighVMSCount vms). > >>> > >>>> * MigrationThreshold - defines a buffer before we start migrat= ing > >>>> VMs > >>>> from the host ( Not quite grasping. If my High limit is 5 does > >>>> this > >>>> mean > >>>> that it will only begin to move VMs when the count reaches 10?= ) > >>> > >>> don't think that there's any relation with "HighLimit". > >>> It means that migration will happen only if there is a difference of X > >>> vms > >>> or more between worst host (source host) to destination host. > >>> > >>> let say that you have 2 hosts. one has 10 vms and the second 8. if the > >>> threshold is 3, no migration will happen (10-8 !> 3). > >> > >> - exactly > >> > >>> > >>>> * SPMVMCountGrace - defines how many slots for VMs should be > >>>> reserved > >>>> on > >>>> SPM hosts (the SPM host should have less load than others, so = this > >>>> variable defines how many VM less it should have) ( Does this = mean > >>>> that > >>>> if I have a host with only 3 VMs the SPM will 3 VMs minus the > >>>> SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) > >>> > >>> you're right, the SPM host will have current + grace VMs in terms of > >>> module > >>> calculations. > >>> I think that this is problematic, it is likely to be selected as worst > >>> host > >>> candidate and that's not the wanted behavior iiuc > >>> imo, we should subtract (-) in overloaded hosts and add (+) in > >>> underutilized. > >> > >> - I think it's correct as it is, if the SpmVmGrace+currentVms > > >> HighVmCount it is overutilized and should be freed if possible. > > > > not sure I understand, let's take an example > > 2 hosts: spm: 8 #vms, hsm: 8 #vms. > > SPMVMCountGrace =3D 2. > > in this case the 'worst' host will be the SPM... shouldn't we deduct 2 = from > > spm and not add? we want less noise there. > > > = > - that's correct, the SPM will be marked as overutilized and the engine > will try to find a host to migrate some vms from the SPM. The SpmGrace > is not about lowering the noise it's about keeping the host less > utilized by running less VMs on it (which will also lower the noise, > because it will give the SPM host worse score when looking for target to > migrate to) got it, thanks :-) > = > --J > = > >> > >> --J > >> > >>> > >>> @Jirka? > >>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users(a)ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >> > >> > = >=20 --===============8580440294044746291==-- From mjames at media-node.com Mon Jun 30 10:31:27 2014 Content-Type: multipart/mixed; boundary="===============0490441142637356795==" MIME-Version: 1.0 From: Maurice James To: users at ovirt.org Subject: [ovirt-users] Spam Re: Spam Cluster Polcies Date: Mon, 30 Jun 2014 10:31:21 -0400 Message-ID: <1687891423.9806.1404138681191.JavaMail.zimbra@media-node.com> In-Reply-To: 1198533102.949114.1404134431296.JavaMail.zimbra@redhat.com --===============0490441142637356795== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks I think I got it now. I can adjust my cluster policy accordingly ----- Original Message ----- From: "Gilad Chaplik" To: "Jiri Moskovcak" Cc: "Maurice James" , "users" Sent: Monday, June 30, 2014 9:20:31 AM Subject: Re: [ovirt-users] Spam Cluster Polcies ----- Original Message ----- > From: "Jiri Moskovcak" > To: "Gilad Chaplik" > Cc: "Maurice James" , "users" > Sent: Monday, June 30, 2014 4:19:06 PM > Subject: Re: [ovirt-users] Spam Cluster Polcies > = > On 06/30/2014 03:11 PM, Gilad Chaplik wrote: > > ----- Original Message ----- > >> From: "Jiri Moskovcak" > >> To: "Gilad Chaplik" , "Maurice James" > >> > >> Cc: "users" > >> Sent: Monday, June 30, 2014 3:57:29 PM > >> Subject: Re: [ovirt-users] Spam Cluster Polcies > >> > >> On 06/30/2014 01:53 PM, Gilad Chaplik wrote: > >>> ----- Original Message ----- > >>>> From: "Maurice James" > >>>> To: "users" > >>>> Sent: Friday, June 27, 2014 1:20:23 AM > >>>> Subject: [ovirt-users] Spam Cluster Polcies > >>>> > >>>> Can someone explain the cluster policies to me? The explanation at > >>>> http://www.ovirt.org/Features/Even_VM_Count_Distribution is not quite > >>>> clicking for me. > >>>> > >>>> > >>>> > >>>> * HighVMSCount - Maximum VM limit. Exceeding it qualifies the = host > >>>> as > >>>> overloaded. ( Understood ) > >>> > >>> minimal #vms on host to enable the module (i.e worst host should have > >>> more > >>> than HighVMSCount vms). > >>> > >>>> * MigrationThreshold - defines a buffer before we start migrat= ing > >>>> VMs > >>>> from the host ( Not quite grasping. If my High limit is 5 does > >>>> this > >>>> mean > >>>> that it will only begin to move VMs when the count reaches 10?= ) > >>> > >>> don't think that there's any relation with "HighLimit". > >>> It means that migration will happen only if there is a difference of X > >>> vms > >>> or more between worst host (source host) to destination host. > >>> > >>> let say that you have 2 hosts. one has 10 vms and the second 8. if the > >>> threshold is 3, no migration will happen (10-8 !> 3). > >> > >> - exactly > >> > >>> > >>>> * SPMVMCountGrace - defines how many slots for VMs should be > >>>> reserved > >>>> on > >>>> SPM hosts (the SPM host should have less load than others, so = this > >>>> variable defines how many VM less it should have) ( Does this = mean > >>>> that > >>>> if I have a host with only 3 VMs the SPM will 3 VMs minus the > >>>> SpmWmGrace? Or is this HighVmCount minus SpmVmGrace count?) > >>> > >>> you're right, the SPM host will have current + grace VMs in terms of > >>> module > >>> calculations. > >>> I think that this is problematic, it is likely to be selected as worst > >>> host > >>> candidate and that's not the wanted behavior iiuc > >>> imo, we should subtract (-) in overloaded hosts and add (+) in > >>> underutilized. > >> > >> - I think it's correct as it is, if the SpmVmGrace+currentVms > > >> HighVmCount it is overutilized and should be freed if possible. > > > > not sure I understand, let's take an example > > 2 hosts: spm: 8 #vms, hsm: 8 #vms. > > SPMVMCountGrace =3D 2. > > in this case the 'worst' host will be the SPM... shouldn't we deduct 2 = from > > spm and not add? we want less noise there. > > > = > - that's correct, the SPM will be marked as overutilized and the engine > will try to find a host to migrate some vms from the SPM. The SpmGrace > is not about lowering the noise it's about keeping the host less > utilized by running less VMs on it (which will also lower the noise, > because it will give the SPM host worse score when looking for target to > migrate to) got it, thanks :-) > = > --J > = > >> > >> --J > >> > >>> > >>> @Jirka? > >>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users(a)ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >> > >> > = >=20 --===============0490441142637356795==--