bonding 802.3ad mode
This is a multi-part message in MIME format. --------------020201020602050902050907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert: "Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode. --------------020201020602050902050907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi all,<br> <br> I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:<br> <div title="" tabindex="0" style="outline-style: none;" __gwt_cell="cell-gwt-uid-164870"> <div class="" style="overflow: hidden; text-overflow: ellipsis; white-space: nowrap;" id="gwt-uid-457_col2_row1">"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])"<br> It seems that the second nic never works while the first one is overloaded.<br> Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.<br> <br> </div> </div> <br> </body> </html> --------------020201020602050902050907--
This is a multi-part message in MIME format. --------------090005030507060807090809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode. Alex On 18/03/15 16:17, Nathanaël Blanchet wrote:
Hi all,
I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert: "Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.
-- This message has been scanned for viruses and dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is believed to be clean.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). --------------090005030507060807090809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode.<br> <br> Alex<br> <br> <br> <br> <div class="moz-cite-prefix">On 18/03/15 16:17, Nathanaël Blanchet wrote:<br> </div> <blockquote cite="mid:5509A533.2060601@abes.fr" type="cite"> <meta http-equiv="content-type" content="text/html; charset=windows-1252"> Hi all,<br> <br> I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:<br> <div title="" tabindex="0" style="outline-style: none;" __gwt_cell="cell-gwt-uid-164870"> <div class="" style="overflow: hidden; text-overflow: ellipsis; white-space: nowrap;" id="gwt-uid-457_col2_row1">"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])"<br> It seems that the second nic never works while the first one is overloaded.<br> Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.<br> <br> </div> </div> <br> <br> -- <br> This message has been scanned for viruses and <br> dangerous content by <a moz-do-not-send="true" href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br> believed to be clean. <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). </pre> </body> </html> --------------090005030507060807090809--
--_000_EE4D679B9474414187D2E27D8B6890F6957842G08CNEXMBPEKD03g0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVhaCwgQWxleCBpcyByaWdodC4gQW5kIGlmIHlvdSB3YW50IHRvIGRvdWJsZSB0aGUgbmV0d29y a+KAmXMgc3BlZWQgaW4gc2luZ2xlIGZsb3csIHRoZSBtb2RlIDAgaXMgb25seSBjaG9pY2UuIEJ1 dCBtb2RlIDAgc2VlbXMgbm90IGJlIHN1cHBvcnRlZCBpbiBvVmlydD8NCg0K5Y+R5Lu25Lq6OiB1 c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyBbbWFpbHRvOnVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnXSDk u6PooaggQWxleCBDcm93DQrlj5HpgIHml7bpl7Q6IDIwMTXlubQz5pyIMTnml6UgMDoyNQ0K5pS2 5Lu25Lq6OiB1c2Vyc0BvdmlydC5vcmcNCuS4u+mimDogUmU6IFtvdmlydC11c2Vyc10gYm9uZGlu ZyA4MDIuM2FkIG1vZGUNCg0KVGhlIGJhbGFuY2luZyBvbiA4MDIuM2FkIG9ubHkgb2NjdXJzIGZv ciBkaWZmZXJlbnQgbmV0d29yayBmbG93cyBiYXNlZCBvbiBhIGhhc2ggb2Ygc291cmNlIGFuZCBk ZXN0aW5hdGlvbiBNQUMgKG9yIGNhbiBiZSBtYWRlIHRvIGFkZCBJUCBhZGRyZXNzZXMgaW50byB0 aGUgY2FsY3VsYXRpb24pLiBBIHNpbmdsZSBmbG93IHdpbGwgb25seSB1c2UgYSBzaW5nbGUgTklD IGluIGFkIG1vZGUuDQoNCkFsZXgNCg0KDQpPbiAxOC8wMy8xNSAxNjoxNywgTmF0aGFuYcOrbCBC bGFuY2hldCB3cm90ZToNCkhpIGFsbCwNCg0KSSdtIHVzZWQgdG8gY3JlYXRlIGEgbW9kZSA0IGJv bmQwIGludGVyZmFjZSB3aXRoIHR3byAxIEdiL3MgaW50ZXJmYWNlcyBvbiBhbGwgbXkgaG9zdHMs IGFuZCBldGh0b29sIGJvbmQwIGdpdmVzIG1lIGEgZnVuY3Rpb25uYWwgMjAwME1iL3MuIEhvd2V2 ZXIsIHdoZW4gaW1wb3J0aW5nIGEgdm0gZnJvbSB0aGUgZXhwb3J0IGRvbWFpbiAoTkZTIHdpdGgg YSBzcGVlZCBvZiA0R0IvcyksIEkgYWx3YXlzIGhhdmUgdGhpcyBhbGVydDoNCiJIb3N0IHNpcGxl IGhhcyBuZXR3b3JrIGludGVyZmFjZSB3aGljaCBleGNlZWRlZCB0aGUgZGVmaW5lZCB0aHJlc2hv bGQgWzk1JV0gKGVtMzogdHJhbnNtaXQgcmF0ZVswJV0sIHJlY2VpdmUgcmF0ZSBbMTAwJV0pIg0K SXQgc2VlbXMgdGhhdCB0aGUgc2Vjb25kIG5pYyBuZXZlciB3b3JrcyB3aGlsZSB0aGUgZmlyc3Qg b25lIGlzIG92ZXJsb2FkZWQuDQpJcyBpdCBhbiBleHBlY3RlZCBiZWhhdmlvdXI/IEkgYmVsaWV2 ZWQgdGhhdCB0aGUgZmxvdyB3YXMgYmFsYW5jZWQgYmV0d2VlbiB0aGUgdHdvIGludGVyZmFjZXMg aW4gODAyLjNhZCBtb2RlLg0KDQoNCi0tDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQNCmRhbmdlcm91cyBjb250ZW50IGJ5IE1haWxTY2FubmVyPGh0dHA6Ly93 d3cubWFpbHNjYW5uZXIuaW5mby8+LCBhbmQgaXMNCmJlbGlldmVkIHRvIGJlIGNsZWFuLg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVXNl cnMgbWFpbGluZyBsaXN0DQoNClVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3Jn Pg0KDQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMNCg0KDQoN Ci0tDQoNClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgYWRkcmVzc2VlIGFu ZCBtYXkgY29udGFpbg0KDQpjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIFVubGVzcyB5b3UgYXJl IHRoYXQgcGVyc29uLCB5b3UgbWF5IG5vdA0KDQpkaXNjbG9zZSBpdHMgY29udGVudHMgb3IgdXNl IGl0IGluIGFueSB3YXkgYW5kIGFyZSByZXF1ZXN0ZWQgdG8gZGVsZXRlDQoNCnRoZSBtZXNzYWdl IGFsb25nIHdpdGggYW55IGF0dGFjaG1lbnRzIGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoN CiJUcmFuc2FjdCIgaXMgb3BlcmF0ZWQgYnkgSW50ZWdyYXRlZCBGaW5hbmNpYWwgQXJyYW5nZW1l bnRzIHBsYy4gMjkNCg0KQ2xlbWVudCdzIExhbmUsIExvbmRvbiBFQzROIDdBRS4gVGVsOiAoMDIw KSA3NjA4IDQ5MDAgRmF4OiAoMDIwKSA3NjA4DQoNCjUzMDAuIChSZWdpc3RlcmVkIG9mZmljZTog YXMgYWJvdmU7IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCg0KdW5kZXIgbnVtYmVy OiAzNzI3NTkyKS4gQXV0aG9yaXNlZCBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNpYWwNCg0K Q29uZHVjdCBBdXRob3JpdHkgKGVudGVyZWQgb24gdGhlIEZpbmFuY2lhbCBTZXJ2aWNlcyBSZWdp c3Rlcjsgbm8uIDE5MDg1NikuDQo= --_000_EE4D679B9474414187D2E27D8B6890F6957842G08CNEXMBPEKD03g0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBcOTg4NFw4QkJFXDY4M0NcNUYwRiI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5ZZWFoLCBBbGV4IGlzIHJpZ2h0LiBBbmQgaWYgeW91IHdhbnQgdG8gZG91YmxlIHRo ZSBuZXR3b3Jr4oCZcyBzcGVlZCBpbiBzaW5nbGUgZmxvdywgdGhlIG1vZGUgMCBpcyBvbmx5IGNo b2ljZS4gQnV0IG1vZGUgMCBzZWVtcyBub3QgYmUgc3VwcG9ydGVkDQogaW4gb1ZpcnQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Ij4gdXNlcnMtYm91bmNlc0BvdmlydC5v cmcgW21haWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4dCI+ 5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQiPkFsZXggQ3Jvdzxicj4N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T dW47Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQiPiAyMDE1PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0 Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTk8 L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDA6MjU8YnI+DQo8L3NwYW4+PGI+5pS25Lu2 5Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gdXNl cnNAb3ZpcnQub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbb3ZpcnQtdXNlcnNdIGJvbmRpbmcgODAy LjNhZCBtb2RlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGJhbGFuY2luZyBvbiA4MDIuM2FkIG9ubHkgb2Nj dXJzIGZvciBkaWZmZXJlbnQgbmV0d29yayBmbG93cyBiYXNlZCBvbiBhIGhhc2ggb2Ygc291cmNl IGFuZCBkZXN0aW5hdGlvbiBNQUMgKG9yIGNhbiBiZSBtYWRlIHRvIGFkZCBJUCBhZGRyZXNzZXMg aW50byB0aGUgY2FsY3VsYXRpb24pLiBBIHNpbmdsZSBmbG93IHdpbGwNCiBvbmx5IHVzZSBhIHNp bmdsZSBOSUMgaW4gYWQgbW9kZS48YnI+DQo8YnI+DQpBbGV4PGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiAxOC8wMy8xNSAxNjoxNywgTmF0aGFuYcOrbCBCbGFuY2hldCB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8YnI+DQo8YnI+DQpJJ20gdXNlZCB0byBjcmVhdGUgYSBt b2RlIDQgYm9uZDAgaW50ZXJmYWNlIHdpdGggdHdvIDEgR2IvcyBpbnRlcmZhY2VzIG9uIGFsbCBt eSBob3N0cywgYW5kIGV0aHRvb2wgYm9uZDAgZ2l2ZXMgbWUgYSBmdW5jdGlvbm5hbCAyMDAwTWIv cy4gSG93ZXZlciwgd2hlbiBpbXBvcnRpbmcgYSB2bSBmcm9tIHRoZSBleHBvcnQgZG9tYWluIChO RlMgd2l0aCBhIHNwZWVkIG9mIDRHQi9zKSwgSSBhbHdheXMgaGF2ZSB0aGlzIGFsZXJ0OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJnd3QtdWlkLTQ1N19jb2wyX3JvdzEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+JnF1b3Q7SG9zdCBzaXBsZSBoYXMgbmV0d29yayBpbnRlcmZhY2Ugd2hp Y2ggZXhjZWVkZWQgdGhlIGRlZmluZWQgdGhyZXNob2xkIFs5NSVdIChlbTM6IHRyYW5zbWl0IHJh dGVbMCVdLCByZWNlaXZlIHJhdGUgWzEwMCVdKSZxdW90Ozxicj4NCkl0IHNlZW1zIHRoYXQgdGhl IHNlY29uZCBuaWMgbmV2ZXIgd29ya3Mgd2hpbGUgdGhlIGZpcnN0IG9uZSBpcyBvdmVybG9hZGVk Ljxicj4NCklzIGl0IGFuIGV4cGVjdGVkIGJlaGF2aW91cj8gSSBiZWxpZXZlZCB0aGF0IHRoZSBm bG93IHdhcyBiYWxhbmNlZCBiZXR3ZWVuIHRoZSB0d28gaW50ZXJmYWNlcyBpbiA4MDIuM2FkIG1v ZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQotLSA8YnI+DQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgPGJyPg0KZGFuZ2Vyb3VzIGNvbnRl bnQgYnkgPGEgaHJlZj0iaHR0cDovL3d3dy5tYWlsc2Nhbm5lci5pbmZvLyI+PGI+TWFpbFNjYW5u ZXI8L2I+PC9hPiwgYW5kIGlzDQo8YnI+DQpiZWxpZXZlZCB0byBiZSBjbGVhbi4gPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlVzZXJzIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0ibWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3ZpcnQub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL2xp c3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIj5odHRwOi8vbGlzdHMub3ZpcnQu b3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlz IG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIGFkZHJlc3NlZSBhbmQgbWF5IGNvbnRh aW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbi4gVW5sZXNzIHlvdSBhcmUgdGhhdCBwZXJzb24sIHlvdSBtYXkg bm90PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5kaXNj bG9zZSBpdHMgY29udGVudHMgb3IgdXNlIGl0IGluIGFueSB3YXkgYW5kIGFyZSByZXF1ZXN0ZWQg dG8gZGVsZXRlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij50aGUgbWVzc2FnZSBhbG9uZyB3aXRoIGFueSBhdHRhY2htZW50cyBhbmQgbm90aWZ5IHVzIGlt bWVkaWF0ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+JnF1b3Q7VHJhbnNhY3QmcXVvdDsgaXMgb3BlcmF0ZWQgYnkgSW50ZWdyYXRlZCBGaW5hbmNp YWwgQXJyYW5nZW1lbnRzIHBsYy4gMjk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPkNsZW1lbnQncyBMYW5lLCBMb25kb24gRUM0TiA3QUUuIFRlbDogKDAy MCkgNzYwOCA0OTAwIEZheDogKDAyMCkgNzYwODxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+NTMwMC4gKFJlZ2lzdGVyZWQgb2ZmaWNlOiBhcyBhYm92ZTsg UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+dW5kZXIgbnVtYmVyOiAzNzI3NTkyKS4gQXV0aG9yaXNl ZCBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNpYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbmR1Y3QgQXV0aG9yaXR5IChlbnRlcmVkIG9uIHRo ZSBGaW5hbmNpYWwgU2VydmljZXMgUmVnaXN0ZXI7IG5vLiAxOTA4NTYpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EE4D679B9474414187D2E27D8B6890F6957842G08CNEXMBPEKD03g0_--
Mode 0 is not supported under a bridge, just like mode 6 On Wed, Mar 18, 2015 at 10:47 PM, Xie, Chao <xiec.fnst@cn.fujitsu.com> wrote:
Yeah, Alex is right. And if you want to double the network’s speed in single flow, the mode 0 is only choice. But mode 0 seems not be supported in oVirt?
*发件人:* users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] *代表 *Alex Crow *发送时间:* 2015年3月19日 0:25 *收件人:* users@ovirt.org *主题:* Re: [ovirt-users] bonding 802.3ad mode
The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode.
Alex
On 18/03/15 16:17, Nathanaël Blanchet wrote:
Hi all,
I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:
"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.
-- This message has been scanned for viruses and dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is believed to be clean.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. 190856).
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Wed, Mar 18, 2015 at 10:57:18PM -0400, Dan Yasny wrote:
Mode 0 is not supported under a bridge, just like mode 6
On Wed, Mar 18, 2015 at 10:47 PM, Xie, Chao <xiec.fnst@cn.fujitsu.com> wrote:
Yeah, Alex is right. And if you want to double the network’s speed in single flow, the mode 0 is only choice. But mode 0 seems not be supported in oVirt?
*发件人:* users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] *代表 *Alex Crow *发送时间:* 2015年3月19日 0:25 *收件人:* users@ovirt.org *主题:* Re: [ovirt-users] bonding 802.3ad mode
The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode.
Alex
On 18/03/15 16:17, Nathanaël Blanchet wrote:
Hi all,
I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:
"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.
To follow up on former ressponses: what do you have on top of your bond? If you have a VM network, multiple guests are expected to have a different hash value for each, and to spread the load on mode 4. If you use the bonds for a host network (e.g. dispaly, migration, storage) you can try mode 0.
This is a multi-part message in MIME format. --------------000408050507090101050409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, thanks for the explanation, but I did'nt find any reason about=20 incompatibility between mode 0 and bridge... Can you give me some=20 sources about this? Ovirt doesn't actually allow it, so it must exist a=20 good reason for that. But for my own, I have several single kvm hosts that support bridge over=20 bonding in mode 0 and vms run fine on it... So, someone can share his experience about this kind of detail? ps: ovirt has a field for configuring custom mode whereas mode 0 is not=20 listed in the predifined list, I didn't make any test, but it seem to be=20 at least possible. Le 19/03/2015 03:57, Dan Yasny a =C3=A9crit :
Mode 0 is not supported under a bridge, just like mode 6
On Wed, Mar 18, 2015 at 10:47 PM, Xie, Chao <xiec.fnst@cn.fujitsu.com=20 <mailto:xiec.fnst@cn.fujitsu.com>> wrote:
Yeah, Alex is right. And if you want to double the network=E2=80=99= s speed in single flow, the mode 0 is only choice. But mode 0 seems not be supported in oVirt?
*=E5=8F=91 =E4=BB=B6=E4=BA=BA:*users-bounces@ovirt.org <mailto:user= s-bounces@ovirt.org> [mailto:users-bounces@ovirt.org <mailto:users-bounces@ovirt.org>] *=E4=BB=A3 =E8=A1=A8 *Alex Crow *=E5=8F=91 =E9=80=81=E6=97=B6=E9=97=B4:*2015=E5=B9=B43=E6=9C=8819=E6= =97=A50:25 *=E6=94=B6=E4=BB=B6=E4=BA=BA:*users@ovirt.org <mailto:users@ovirt.o= rg> *=E4=B8=BB=E9=A2=98:*Re: [ovirt-users] bonding 802.3ad mode
The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode.
Alex
On 18/03/15 16:17, Nathana=C3=ABl Blanchet wrote:
Hi all,
I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:
"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.
--=20 This message has been scanned for viruses and dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is believed to be clean.
_______________________________________________
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
--=20
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to del= ete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 76= 08
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. = 190856).
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--------------000408050507090101050409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> Hello, thanks for the explanation, but I did'nt find any reason about incompatibility between mode 0 and bridge... Can you give me some sources about this? Ovirt doesn't actually allow it, so it must exist a good reason for that.<br> But for my own, I have several single kvm hosts that support bridge over bonding in mode 0 and vms run fine on it...<br> So, someone can share his experience about this kind of detail?<br> <br> ps: ovirt has a field for configuring custom mode whereas mode 0 is not listed in the predifined list, I didn't make any test, but it seem to be at least possible.<br> <br> <div class=3D"moz-cite-prefix">Le 19/03/2015 03:57, Dan Yasny a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:CALLXwb6HyyT-xZ00gw1qKLyd=3DH6UHf1p6Nw5m1R2e+p+sGaWow@mail.gm= ail.com" type=3D"cite"> <div dir=3D"ltr">Mode 0 is not supported under a bridge, just like mode 6<br> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Wed, Mar 18, 2015 at 10:47 PM, Xie, Chao <span dir=3D"ltr"><<a moz-do-not-send=3D"true" href=3D"mailto:xiec.fnst@cn.fujitsu.com" target=3D"_blank= ">xiec.fnst@cn.fujitsu.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor=3D"white" link=3D"blue" vlink=3D"purple" lang=3D"ZH-CN"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Calibri","sans-seri= f";color:#1f497d" lang=3D"EN-US">Yeah, Alex is right. And if you want to double the network=E2=80=99s speed in single flo= w, the mode 0 is only choice. But mode 0 seems not be supported in oVirt?</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Calibri","sans-seri= f";color:#1f497d" lang=3D"EN-US">=C2=A0</span></p> <div> <div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:SimSun;= color:windowtext">=E5=8F=91 =E4=BB=B6=E4=BA=BA<span lang=3D"EN-US">:</spa= n></span></b><span style=3D"font-size:10.0pt;font-family:SimSun;color:windowtext" lang=3D"EN-US"> <a moz-do-not-send=3D"true" href=3D"mailto:users-bounces@ovirt.org" target=3D"_blank">users-bounces@ovirt.org</a> [mailto:<a moz-do-not-send=3D"true" href=3D"mailto:users-bounces@ovirt.org" target=3D"_blank">users-bounces@ovirt.org</a>= ] </span><b><span style=3D"font-size:10.0pt;font-family:SimSun;= color:windowtext">=E4=BB=A3 =E8=A1=A8 </span> </b><span style=3D"font-size:10.0pt;font-family:SimSun;co= lor:windowtext" lang=3D"EN-US">Alex Crow<br> </span><b><span style=3D"font-size:10.0pt;font-family:SimSun;= color:windowtext">=E5=8F=91 =E9=80=81=E6=97=B6=E9=97=B4<span lang=3D"EN-U= S">:</span></span></b><span style=3D"font-size:10.0pt;font-family:SimSun;color:windowtext" lang=3D"EN-US"> 2015</span><span style=3D"font-size:10.0pt;font-family:SimSun;co= lor:windowtext">=E5=B9=B4<span lang=3D"EN-US">3</span>=E6=9C=88<span lang=3D= "EN-US">19</span>=E6=97=A5<span lang=3D"EN-US"> 0:25<br> </span><b>=E6=94=B6=E4=BB=B6=E4=BA=BA<span lang= =3D"EN-US">:</span></b><span lang=3D"EN-US"> <a moz-do-not-send=3D"true" href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a><br> </span><b>=E4=B8=BB=E9=A2=98<span lang=3D"EN-US= ">:</span></b><span lang=3D"EN-US"> Re: [ovirt-users] bonding 802.3ad mode</span></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US">=C2=A0</spa= n></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><= span lang=3D"EN-US">The balancing on 802.3ad only occurs for different network flows based on a hash of source and destination MAC (or can be made to add IP addresses into the calculation). A single flow will only use a single NIC in ad mode.<br> <br> Alex<br> <br> <br> </span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US">On 18/03/= 15 16:17, Nathana=C3=ABl Blanchet wrote:</span></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all,<b= r> <br> I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert:</span></p> <div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">"Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])"<br> It seems that the second nic never works while the first one is overloaded.<br> Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.</span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><br> <br> -- <br> This message has been scanned for viruses and <br=
http://lists.ovirt.org/mailman/listinfo/users</a></span></pre> </blockquote> <p class=3D"MsoNormal"><span lang=3D"EN-US"><br> <br> </span></p> <pre><span lang=3D"EN-US">-- </span></pre> <pre><span lang=3D"EN-US">This message is intended only= for the addressee and may contain</span></pre> <pre><span lang=3D"EN-US">confidential information. Unl= ess you are that person, you may not</span></pre> <pre><span lang=3D"EN-US">disclose its contents or use = it in any way and are requested to delete</span></pre> <pre><span lang=3D"EN-US">the message along with any at= tachments and notify us immediately.</span></pre> <pre><span lang=3D"EN-US">"Transact" is operated by Int= egrated Financial Arrangements plc. 29</span></pre> <pre><span lang=3D"EN-US">Clement's Lane, London EC4N 7= AE. Tel: (020) 7608 4900 Fax: (020) 7608</span></pre> <pre><span lang=3D"EN-US">5300. (Registered office: as = above; Registered in England and Wales</span></pre> <pre><span lang=3D"EN-US">under number: 3727592). Autho= rised and regulated by the Financial</span></pre> <pre><span lang=3D"EN-US">Conduct Authority (entered on=
dangerous content by <a moz-do-not-send=3D"true" href=3D"http://www.mailscanner.info/" target=3D"_blank"><b>MailScanner</b></a>, and i= s <br> believed to be clean. <br> <br> <br> </span></p> <pre><span lang=3D"EN-US">___________________________= ____________________</span></pre> <pre><span lang=3D"EN-US">Users mailing list</span></= pre> <pre><span lang=3D"EN-US"><a moz-do-not-send=3D"true"= href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.org</a></s= pan></pre> <pre><span lang=3D"EN-US"><a moz-do-not-send=3D"true"= href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"= the Financial Services Register; no. 190856).</span></pre> </div> </div> <br> _______________________________________________<br> Users mailing list<br> <a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org"=
Users@ovirt.org</a><br> <a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank">http://lists.ovirt.org/mailman/listinfo= /users</a><br> <br> </blockquote> </div> <br> </div> </div> <br> <fieldset class=3D"mimeAttachmentHeader"></fieldset> <br> <pre wrap=3D"">_______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org">Use= rs@ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman= /listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </body> </html>
--------------000408050507090101050409--
On Fri, Mar 20, 2015 at 04:48:29PM +0100, Nathanaël Blanchet wrote:
Hello, thanks for the explanation, but I did'nt find any reason about incompatibility between mode 0 and bridge... Can you give me some sources about this? Ovirt doesn't actually allow it, so it must exist a good reason for that.
I can quote Jiri Pirko https://bugzilla.redhat.com/show_bug.cgi?id=1094842#c0 """ Do not use tlb or alb in bridge, never! It does not work, that's it. The reason is it mangles source macs in xmit frames and arps. When it is possible, just use mode 4 (lacp). That should be always possible because all enterprise switches support that. Generally, for 99% of use cases, you *should* use mode 4. There is no reason to use other modes. """
But for my own, I have several single kvm hosts that support bridge over bonding in mode 0 and vms run fine on it... So, someone can share his experience about this kind of detail?
ps: ovirt has a field for configuring custom mode whereas mode 0 is not listed in the predifined list, I didn't make any test, but it seem to be at least possible.
The bug referred above intends to make it a bit harder to make this mistake. But in the good-old Un*x way, oVirt allows you to tweak things that you actually should not, for fun or research.
Hello Dan, Initially, I wanted to reduce the time of import process from the export domain to my FC storage domain. In this context, I'm not limited by the SAN (8Gbits) or the disk I/O (raid 5), but by the gigabit NIC. My initial network configuration was to aggregate 2 nic (1 and 3) to a mode 4 bond0 and making vlan over it. So mode 4 is the best mode for this because each vms ha its own MAC adress, so the 2gigabits BW are used as expected. But the problematic of importing vms (the same as migrating them) is not the same, because the flow is unique, so the bandwith is never useful. What I decided to do, is to create a second non-LACP bridge bond1 aggragating nic2 and nic4 which is dedicated to the ovirtmgmt bridgeless network. Because this one is bridgeless, I add in the custom field the "mode=4 miion=100) options to have the round robin mode. It seems to be ok after testing... please, tell me if I do something wrong. Le 23/03/2015 10:32, Dan Kenigsberg a écrit :
Hello, thanks for the explanation, but I did'nt find any reason about incompatibility between mode 0 and bridge... Can you give me some sources about this? Ovirt doesn't actually allow it, so it must exist a good reason for that. I can quote Jiri Pirko https://bugzilla.redhat.com/show_bug.cgi?id=1094842#c0 """ Do not use tlb or alb in bridge, never! It does not work, that's it. The reason is it mangles source macs in xmit frames and arps. When it is
On Fri, Mar 20, 2015 at 04:48:29PM +0100, Nathanaël Blanchet wrote: possible, just use mode 4 (lacp). That should be always possible because all enterprise switches support that. Generally, for 99% of use cases, you *should* use mode 4. There is no reason to use other modes. """
But for my own, I have several single kvm hosts that support bridge over bonding in mode 0 and vms run fine on it... So, someone can share his experience about this kind of detail?
ps: ovirt has a field for configuring custom mode whereas mode 0 is not listed in the predifined list, I didn't make any test, but it seem to be at least possible. The bug referred above intends to make it a bit harder to make this mistake. But in the good-old Un*x way, oVirt allows you to tweak things that you actually should not, for fun or research.
On Mon, Mar 23, 2015 at 12:58:48PM +0100, Nathanaël Blanchet wrote:
Hello Dan,
Initially, I wanted to reduce the time of import process from the export domain to my FC storage domain. In this context, I'm not limited by the SAN (8Gbits) or the disk I/O (raid 5), but by the gigabit NIC. My initial network configuration was to aggregate 2 nic (1 and 3) to a mode 4 bond0 and making vlan over it. So mode 4 is the best mode for this because each vms ha its own MAC adress, so the 2gigabits BW are used as expected. But the problematic of importing vms (the same as migrating them) is not the same, because the flow is unique, so the bandwith is never useful. What I decided to do, is to create a second non-LACP bridge bond1 aggragating nic2 and nic4 which is dedicated to the ovirtmgmt bridgeless network. Because this one is bridgeless, I add in the custom field the "mode=4 miion=100) options to have the round robin mode. It seems to be ok after testing... please, tell me if I do something wrong.
it seems that you have a typo somewhere: "non-LACP bridge bond1... dedicated to the ovirtmgmt bridgeless network". I suppose bond1 is a bond with no bridge involved. If this is the case, I believe that you're fine.
cool, you should read "mode=0 miion=100" instead of "mode=4 miion=100" :) but we are ok on the finality ! Le 23/03/2015 17:00, Dan Kenigsberg a écrit :
On Mon, Mar 23, 2015 at 12:58:48PM +0100, Nathanaël Blanchet wrote:
Hello Dan,
Initially, I wanted to reduce the time of import process from the export domain to my FC storage domain. In this context, I'm not limited by the SAN (8Gbits) or the disk I/O (raid 5), but by the gigabit NIC. My initial network configuration was to aggregate 2 nic (1 and 3) to a mode 4 bond0 and making vlan over it. So mode 4 is the best mode for this because each vms ha its own MAC adress, so the 2gigabits BW are used as expected. But the problematic of importing vms (the same as migrating them) is not the same, because the flow is unique, so the bandwith is never useful. What I decided to do, is to create a second non-LACP bridge bond1 aggragating nic2 and nic4 which is dedicated to the ovirtmgmt bridgeless network. Because this one is bridgeless, I add in the custom field the "mode=4 miion=100) options to have the round robin mode. It seems to be ok after testing... please, tell me if I do something wrong. it seems that you have a typo somewhere: "non-LACP bridge bond1... dedicated to the ovirtmgmt bridgeless network". I suppose bond1 is a bond with no bridge involved. If this is the case, I believe that you're fine.
Bonjour Nathanael, You haven't mentioned which version of oVirt you were using - I suspect it's pre-3.5 and therefore this isn't fixed yet: https://bugzilla.redhat.com/show_bug.cgi?id=1114085
From 3.5 onwards the warning should not appear for a bond (in aggregating mode) if only one of its slaves is overloaded.
A bientot, Lior. On 18/03/15 18:17, Nathanaël Blanchet wrote:
Hi all,
I'm used to create a mode 4 bond0 interface with two 1 Gb/s interfaces on all my hosts, and ethtool bond0 gives me a functionnal 2000Mb/s. However, when importing a vm from the export domain (NFS with a speed of 4GB/s), I always have this alert: "Host siple has network interface which exceeded the defined threshold [95%] (em3: transmit rate[0%], receive rate [100%])" It seems that the second nic never works while the first one is overloaded. Is it an expected behaviour? I believed that the flow was balanced between the two interfaces in 802.3ad mode.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (6)
-
Alex Crow -
Dan Kenigsberg -
Dan Yasny -
Lior Vernia -
Nathanaël Blanchet -
Xie, Chao