6:17 p.m.
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--
6:25 p.m.
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(a)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://...
</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--
4:47 a.m.
New subject: 答复: bonding 802.3ad mode
--_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_--
4:57 a.m.
New subject: 答复: bonding 802.3ad mode
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(a)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(a)ovirt.org [mailto:users-bounces@ovirt.org] *代表 *Alex
Crow
*发送时间:* 2015年3月19日 0:25
*收件人:* users(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:34 p.m.
New subject: 答复: bonding 802.3ad mode
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(a)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(a)ovirt.org [mailto:users-bounces@ovirt.org] *代表 *Alex
> Crow
> *发送时间:* 2015年3月19日 0:25
> *收件人:* users(a)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.
5:48 p.m.
New subject: 答复: bonding 802.3ad mode
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 :
<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(a)cn.fujitsu.com</a>&gt;</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(a)ovirt.org</a
[mailto:<a moz-do-not-send=3D"true"
href=3D"mailto:users-bounces@ovirt.org"
target=3D"_blank">users-bounces(a)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(a)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=
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(a)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"=
>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=
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(a)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(a)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--
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(a)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(a)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(a)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(a)ovirt.org <mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------000408050507090101050409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html
11:32 a.m.
New subject: 答复: bonding 802.3ad mode
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.
1:58 p.m.
New subject: 答复: bonding 802.3ad mode
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 :
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.
6 p.m.
New subject: 答复: bonding 802.3ad mode
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.
6:20 p.m.
New subject: 答复: bonding 802.3ad mode
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.
3:19 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3533
days inactive
3538
days old
10 comments
6 participants
participants (6)
-
Alex Crow -
Dan Kenigsberg -
Dan Yasny -
Lior Vernia -
Nathanaël Blanchet -
Xie, Chao