[Users] mac address re-use
--_000_9BE6F493F83A594DA60C45E6A09DC5AC01709931AUSP01DAG0201co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable my 3.2 install seems to be reusing mac address of formerly-deleted guests. = is this the normal behavior, and or can i turn this off? i would prefer t= o have a unique mac address for each new VM created. thanks, jonathan ________________________________ This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind SKO= POS to any order or other contract unless pursuant to explicit written agre= ement or government initiative expressly permitting the use of e-mail for s= uch purpose. --_000_9BE6F493F83A594DA60C45E6A09DC5AC01709931AUSP01DAG0201co_ Content-Type: text/html; charset="us-ascii" Content-ID: <1C15068072CEE84099EA5BF1C178CF8D@collaborationhost.net> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
</head> <body style=3D"color:rgb(0,0,0); font-size:14px; font-family:Calibri,sans-s= erif; word-wrap:break-word"> <div> <div> <div>my 3.2 install seems to be reusing mac address of formerly-deleted gue= sts. is this the normal behavior, and or can i turn this off? i= would prefer to have a unique mac address for each new VM created.</div> <div><br> </div> <div>thanks,</div> <div>jonathan</div> <div> <div></div> </div> </div> </div> <br> <hr> <font color=3D"Gray" face=3D"Arial" size=3D"1">This is a PRIVATE message. I= f you are not the intended recipient, please delete without copying and kin= dly advise us by e-mail of the mistake in delivery. NOTE: Regardless of con= tent, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit wri= tten agreement or government initiative expressly permitting the use of e-m= ail for such purpose.</font> </body> </html> --_000_9BE6F493F83A594DA60C45E6A09DC5AC01709931AUSP01DAG0201co_--
This is a multi-part message in MIME format. --------------040105080202010608020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/07/2013 05:22 PM, Jonathan Horne wrote:
my 3.2 install seems to be reusing mac address of formerly-deleted guests. is this the normal behavior, and or can i turn this off? i would prefer to have a unique mac address for each new VM created.
thanks, jonathan
------------------------------------------------------------------------ This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users I believe re-use is intentional. I suspect oVirt uses the IEEE [1] space allocated to Qumranet and that space is relatively small. There were previous discussions on the list regarding the probability of
collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and because a program shouldn't just go randomly creating addresses from any available OUI block.
Cheers, Keith [1] http://standards.ieee.org/develop/regauth/oui/public.html --------------040105080202010608020001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 01/07/2013 05:22 PM, Jonathan Horne wrote:<br> </div> <blockquote cite="mid:9BE6F493F83A594DA60C45E6A09DC5AC01709931@AUSP01DAG0201.collaborationhost.net" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div> <div> <div>my 3.2 install seems to be reusing mac address of formerly-deleted guests. is this the normal behavior, and or can i turn this off? i would prefer to have a unique mac address for each new VM created.</div> <div><br> </div> <div>thanks,</div> <div>jonathan</div> <div> </div> </div> </div> <br> <hr> <font color="Gray" face="Arial" size="1">This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.</font> <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> I believe re-use is intentional. I suspect oVirt uses the IEEE [1] space allocated to Qumranet and that space is relatively small. There were previous discussions on the list regarding the probability of collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and because a program shouldn't just go randomly creating addresses from any available OUI block.<br> <br> Cheers,<br> Keith<br> <br> [1] <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://standards.ieee.org/develop/regauth/oui/public.html">http://standards.ieee.org/develop/regauth/oui/public.html</a><br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </body> </html> --------------040105080202010608020001--
------=_Part_954104_2040875929.1357625912339 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Keith summed things quite right as far as I know (I did not know about the = range allocated to Qumranet)=20
From code perspective - We have a MacPoolManager infrastructure which holds= a pool of Mac addresses, and per deletion of VM, the mac address is return= ed to the pool.=20
----- Original Message -----
From: "Keith Robertson" <kroberts@redhat.com> To: "Jonathan Horne" <jhorne@skopos.us> Cc: "users" <users@ovirt.org> Sent: Tuesday, January 8, 2013 5:15:04 AM Subject: Re: [Users] mac address re-use
On 01/07/2013 05:22 PM, Jonathan Horne wrote:
my 3.2 install seems to be reusing mac address of formerly-deleted guests. is this the normal behavior, and or can i turn this off? i would prefer to have a unique mac address for each new VM created. =20
thanks, =20 jonathan =20
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. =20
_______________________________________________ =20 Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users =20 I believe re-use is intentional. I suspect oVirt uses the IEEE [1] space allocated to Qumranet and that space is relatively small. There were previous discussions on the list regarding the probability of collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and because a program shouldn't just go randomly creating addresses from any available OUI block.
Cheers, Keith=D7=9F
[1] http://standards.ieee.org/develop/regauth/oui/public.html
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
------=_Part_954104_2040875929.1357625912339 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Keith summed things quite right as far as I know (I d= id not know about the range allocated to Qumranet)<div>From code perspectiv= e - We have a MacPoolManager infrastructure which holds a pool of Mac addre= sses, and per deletion of VM, the mac address is returned to the pool.</div=
<div><br></div><div><br><br><hr id=3D"zwchr"><blockquote style=3D"border-l= eft:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;= font-weight:normal;font-style:normal;text-decoration:none;font-family:Helve= tica,Arial,sans-serif;font-size:12pt;" id=3D"DWT607"><b>From: </b>"Keith Ro= bertson" <kroberts@redhat.com><br><b>To: </b>"Jonathan Horne" <jho= rne@skopos.us><br><b>Cc: </b>"users" <users@ovirt.org><br><b>Sent:= </b>Tuesday, January 8, 2013 5:15:04 AM<br><b>Subject: </b>Re: [Users] mac= address re-use<br><br> =20 =20 =20 =20 <div class=3D"moz-cite-prefix">On 01/07/2013 05:22 PM, Jonathan Horne wrote:<br> </div> <blockquote cite=3D"mid:9BE6F493F83A594DA60C45E6A09DC5AC01709931@AUSP01= DAG0201.collaborationhost.net"> =20 <div> <div> <div>my 3.2 install seems to be reusing mac address of formerly-deleted guests. is this the normal behavior, and or can i turn this off? i would prefer to have a unique m= ac address for each new VM created.</div> <div><br> </div> <div>thanks,</div> <div>jonathan</div> <div> </div> </div> </div> <br> <hr> <font color=3D"Gray" face=3D"Arial" size=3D"1">This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.</font> <br> <fieldset class=3D"mimeAttachmentHeader"></fieldset> <br> <pre>_______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org" targe= t=3D"_blank">Users@ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman/l= istinfo/users" target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/us= ers</a> </pre> </blockquote> I believe re-use is intentional. I suspect oVirt uses the IEEE [1= ] space allocated to Qumranet and that space is relatively small. There were previous discussions on the list regarding the probability of collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and because a program shouldn't just go randomly creating addresses from any available OUI block.<br> <br> Cheers,<br> Keith=D7=9F<br><br><br><br> <br> [1] =20 <a href=3D"http://standards.ieee.org/develop/regauth/oui/public.html" t= arget=3D"_blank">http://standards.ieee.org/develop/regauth/oui/public.html<= /a><br> =20 =20
<br>_______________________________________________<br>Users mailing list<b= r>Users@ovirt.org<br>http://lists.ovirt.org/mailman/listinfo/users<br></blo= ckquote><br></div></div></body></html> ------=_Part_954104_2040875929.1357625912339--
--_000_5F9E965F5A80BC468BE5F40576769F09101FE9C0exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 dGlzIDIwMTMtMDEtMDgga2xvY2thbiAwMToxOCAtMDUwMCBza3JldiBZYWlyIFphc2xhdnNreToN CktlaXRoIHN1bW1lZCB0aGluZ3MgcXVpdGUgcmlnaHQgYXMgZmFyIGFzIEkga25vdyAoSSBkaWQg bm90IGtub3cgYWJvdXQgdGhlIHJhbmdlIGFsbG9jYXRlZCB0byBRdW1yYW5ldCkNCkZyb20gY29k ZSBwZXJzcGVjdGl2ZSAtIFdlIGhhdmUgYSBNYWNQb29sTWFuYWdlciBpbmZyYXN0cnVjdHVyZSB3 aGljaCBob2xkcyBhIHBvb2wgb2YgTWFjIGFkZHJlc3NlcywgYW5kIHBlciBkZWxldGlvbiBvZiBW TSwgdGhlIG1hYyBhZGRyZXNzIGlzIHJldHVybmVkIHRvIHRoZSBwb29sLg0KV2hpY2ggbWVhbnMg dGhhdCBpZiB5b3Ugc2V0IHVwIHR3byBvVmlydCBzeXN0ZW1zIGluZGVwZW5kYW50bHk7IG9uZSBm b3IgcHJvZHVjdGlvbiBhbmQgb25lIGZvciB0ZXN0aW5nLCB5b3Ugd2lsbCBnZXQgY29sbGlzaW9u cz8NCg0KL0thcmxpDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRnJvbTogIktlaXRoIFJvYmVydHNvbiIgPGtyb2JlcnRzQHJlZGhhdC5jb20+DQpUbzogIkpv bmF0aGFuIEhvcm5lIiA8amhvcm5lQHNrb3Bvcy51cz4NCkNjOiAidXNlcnMiIDx1c2Vyc0Bvdmly dC5vcmc+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDgsIDIwMTMgNToxNTowNCBBTQ0KU3ViamVj dDogUmU6IFtVc2Vyc10gbWFjIGFkZHJlc3MgcmUtdXNlDQoNCk9uIDAxLzA3LzIwMTMgMDU6MjIg UE0sIEpvbmF0aGFuIEhvcm5lIHdyb3RlOg0KDQpteSAzLjIgaW5zdGFsbCBzZWVtcyB0byBiZSBy ZXVzaW5nIG1hYyBhZGRyZXNzIG9mIGZvcm1lcmx5LWRlbGV0ZWQgZ3Vlc3RzLiAgaXMgdGhpcyB0 aGUgbm9ybWFsIGJlaGF2aW9yLCBhbmQgb3IgY2FuIGkgdHVybiB0aGlzIG9mZj8gIGkgd291bGQg cHJlZmVyIHRvIGhhdmUgYSB1bmlxdWUgbWFjIGFkZHJlc3MgZm9yIGVhY2ggbmV3IFZNIGNyZWF0 ZWQuDQoNCg0KdGhhbmtzLA0Kam9uYXRoYW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6 IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8g YmluZCBTS09QT1MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFu dCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUg ZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4N Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpV c2VycyBtYWlsaW5nIGxpc3QNClVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3Jn Pg0KaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQoNCg0KSSBi ZWxpZXZlIHJlLXVzZSBpcyBpbnRlbnRpb25hbC4gIEkgc3VzcGVjdCBvVmlydCB1c2VzIHRoZSBJ RUVFIFsxXSBzcGFjZSBhbGxvY2F0ZWQgdG8gUXVtcmFuZXQgYW5kIHRoYXQgc3BhY2UgaXMgcmVs YXRpdmVseSBzbWFsbC4gIFRoZXJlIHdlcmUgcHJldmlvdXMgZGlzY3Vzc2lvbnMgb24gdGhlIGxp c3QgcmVnYXJkaW5nIHRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zL2V4aGF1c3Rpb24sIElJ UkMuICBJbiBhbnkgY2FzZSwgeW91IHdhbnQgcmUtdXNlIHRvIHByZXZlbnQgdGhlIHBvc3NpYmls aXR5IG9mIGV4aGF1c3Rpb24gYW5kIGJlY2F1c2UgYSBwcm9ncmFtIHNob3VsZG4ndCBqdXN0IGdv IHJhbmRvbWx5IGNyZWF0aW5nIGFkZHJlc3NlcyBmcm9tIGFueSBhdmFpbGFibGUgT1VJIGJsb2Nr Lg0KDQpDaGVlcnMsDQpLZWl0aNefDQoNCg0KDQoNClsxXSBodHRwOi8vc3RhbmRhcmRzLmllZWUu b3JnL2RldmVsb3AvcmVnYXV0aC9vdWkvcHVibGljLmh0bWwNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVzZXJzIG1haWxpbmcgbGlzdA0KVXNlcnNA b3ZpcnQub3JnDQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMN Cg0KDQoNCg== --_000_5F9E965F5A80BC468BE5F40576769F09101FE9C0exchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQp0aXMgMjAxMy0wMS0w OCBrbG9ja2FuIDAxOjE4IC0wNTAwIHNrcmV2IFlhaXIgWmFzbGF2c2t5Og0KPGJsb2NrcXVvdGUg dHlwZT0iQ0lURSI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPktlaXRoIHN1bW1lZCB0aGluZ3MgcXVp dGUgcmlnaHQgYXMgZmFyIGFzIEkga25vdyAoSSBkaWQgbm90IGtub3cgYWJvdXQgdGhlIHJhbmdl IGFsbG9jYXRlZCB0byBRdW1yYW5ldCk8L2ZvbnQ+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJDSVRFIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+RnJvbSBjb2RlIHBlcnNwZWN0aXZl IC0gV2UgaGF2ZSBhIE1hY1Bvb2xNYW5hZ2VyIGluZnJhc3RydWN0dXJlIHdoaWNoIGhvbGRzIGEg cG9vbCBvZiBNYWMgYWRkcmVzc2VzLCBhbmQgcGVyIGRlbGV0aW9uIG9mIFZNLCB0aGUgbWFjIGFk ZHJlc3MgaXMgcmV0dXJuZWQgdG8gdGhlIHBvb2wuPC9mb250Pjxicj4NCjwvYmxvY2txdW90ZT4N CldoaWNoIG1lYW5zIHRoYXQgaWYgeW91IHNldCB1cCB0d28gb1ZpcnQgc3lzdGVtcyBpbmRlcGVu ZGFudGx5OyBvbmUgZm9yIHByb2R1Y3Rpb24gYW5kIG9uZSBmb3IgdGVzdGluZywgeW91IHdpbGwg Z2V0IGNvbGxpc2lvbnM/PGJyPg0KPGJyPg0KL0thcmxpPGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iQ0lURSI+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Q0lURSI+PGJyPg0KPGJyPg0KPGhyIGFsaWduPSJjZW50ZXIiPg0KPGJyPg0KPGJsb2NrcXVvdGU+ PGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPkZyb206IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMw MDAwMDAiPiZxdW90O0tlaXRoIFJvYmVydHNvbiZxdW90OyAmbHQ7a3JvYmVydHNAcmVkaGF0LmNv bSZndDs8L2ZvbnQ+PGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlRvOiA8L2ZvbnQ+PC9i Pjxmb250IGNvbG9yPSIjMDAwMDAwIj4mcXVvdDtKb25hdGhhbiBIb3JuZSZxdW90OyAmbHQ7amhv cm5lQHNrb3Bvcy51cyZndDs8L2ZvbnQ+PGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPkNj OiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAwIj4mcXVvdDt1c2VycyZxdW90OyAmbHQ7 dXNlcnNAb3ZpcnQub3JnJmd0OzwvZm9udD48YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ U2VudDogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+VHVlc2RheSwgSmFudWFyeSA4 LCAyMDEzIDU6MTU6MDQgQU08L2ZvbnQ+PGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlN1 YmplY3Q6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlJlOiBbVXNlcnNdIG1hYyBh ZGRyZXNzIHJlLXVzZTwvZm9udD48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPjxmb250IGNvbG9yPSIj MDAwMDAwIj5PbiAwMS8wNy8yMDEzIDA1OjIyIFBNLCBKb25hdGhhbiBIb3JuZSB3cm90ZTo8L2Zv bnQ+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iQ0lURSI+DQo8YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlPjxmb250IGNvbG9yPSIjMDAw MDAwIj5teSAzLjIgaW5zdGFsbCBzZWVtcyB0byBiZSByZXVzaW5nIG1hYyBhZGRyZXNzIG9mIGZv cm1lcmx5LWRlbGV0ZWQgZ3Vlc3RzLiAmbmJzcDtpcyB0aGlzIHRoZSBub3JtYWwgYmVoYXZpb3Is IGFuZCBvciBjYW4gaSB0dXJuIHRoaXMgb2ZmPyAmbmJzcDtpIHdvdWxkIHByZWZlciB0byBoYXZl IGEgdW5pcXVlIG1hYyBhZGRyZXNzIGZvciBlYWNoIG5ldyBWTSBjcmVhdGVkLjwvZm9udD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+DQo8YmxvY2txdW90ZT48YnI+DQo8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJD SVRFIj4NCjxibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGU+PGZvbnQgY29sb3I9IiMwMDAwMDAiPnRo YW5rcyw8L2ZvbnQ+IDwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+DQo8YmxvY2txdW90ZT48Zm9u dCBjb2xvcj0iIzAwMDAwMCI+am9uYXRoYW48L2ZvbnQ+IDwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVv dGU+DQo8YmxvY2txdW90ZT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGU+PGJyPg0KPGhyIGFsaWduPSJjZW50ZXIiPg0KPGJyPg0KPGZvbnQgc2l6ZT0iMSI+PGZv bnQgY29sb3I9IiNiZWJlYmUiPlRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5n IGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbiBkZWxpdmVy eS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3Bl cmF0ZSB0byBiaW5kDQogU0tPUE9TIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxl c3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBp bml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNo IHB1cnBvc2UuPC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+DQo8L2ZvbnQ+PGJy Pg0KPGJyPg0KPHByZT4KPGZvbnQgY29sb3I9IiMwMDAwMDAiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9mb250Pgo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+ VXNlcnMgbWFpbGluZyBsaXN0PC9mb250Pgo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGEgaHJlZj0i bWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3ZpcnQub3JnPC9hPjwvZm9udD4KPGZvbnQg Y29sb3I9IiMwMDAwMDAiPjxhIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9s aXN0aW5mby91c2VycyI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vz ZXJzPC9hPjwvZm9udD4KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0iIzAwMDAw MCI+SSBiZWxpZXZlIHJlLXVzZSBpcyBpbnRlbnRpb25hbC4mbmJzcDsgSSBzdXNwZWN0IG9WaXJ0 IHVzZXMgdGhlIElFRUUgWzFdIHNwYWNlIGFsbG9jYXRlZCB0byBRdW1yYW5ldCBhbmQgdGhhdCBz cGFjZSBpcyByZWxhdGl2ZWx5IHNtYWxsLiZuYnNwOyBUaGVyZSB3ZXJlIHByZXZpb3VzIGRpc2N1 c3Npb25zIG9uIHRoZSBsaXN0IHJlZ2FyZGluZyB0aGUgcHJvYmFiaWxpdHkgb2YgY29sbGlzaW9u cy9leGhhdXN0aW9uLCBJSVJDLiZuYnNwOw0KIEluIGFueSBjYXNlLCB5b3Ugd2FudCByZS11c2Ug dG8gcHJldmVudCB0aGUgcG9zc2liaWxpdHkgb2YgZXhoYXVzdGlvbiBhbmQgYmVjYXVzZSBhIHBy b2dyYW0gc2hvdWxkbid0IGp1c3QgZ28gcmFuZG9tbHkgY3JlYXRpbmcgYWRkcmVzc2VzIGZyb20g YW55IGF2YWlsYWJsZSBPVUkgYmxvY2suPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIj MDAwMDAwIj5DaGVlcnMsPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5LZWl0aNef PC9mb250Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAw Ij5bMV0gPGEgaHJlZj0iaHR0cDovL3N0YW5kYXJkcy5pZWVlLm9yZy9kZXZlbG9wL3JlZ2F1dGgv b3VpL3B1YmxpYy5odG1sIj4NCmh0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZGV2ZWxvcC9yZWdh dXRoL291aS9wdWJsaWMuaHRtbDwvYT48L2ZvbnQ+PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMw MDAwMDAiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9m b250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5Vc2VycyBtYWlsaW5nIGxpc3Q8L2ZvbnQ+ PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPlVzZXJzQG92aXJ0Lm9yZzwvZm9udD48YnI+DQo8 Zm9udCBjb2xvcj0iIzAwMDAwMCI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VzZXJzPC9mb250Pjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxicj4NCjwvYmxvY2tx dW90ZT4NCjxicj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F9E965F5A80BC468BE5F40576769F09101FE9C0exchange21_--
------=_Part_961824_554760252.1357627942039 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You can always set a new range of mac addresses using -=20 engine-config -g MacPoolRanges (to see the current range)=20 and then engine-config -s MacPoolRanges=3D<new range>=20 ----- Original Message -----
From: "Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Keith Robertson" <kroberts@redhat.com>, "users" <users@ovirt.org> Sent: Tuesday, January 8, 2013 8:29:49 AM Subject: Re: [Users] mac address re-use
tis 2013-01-08 klockan 01:18 -0500 skrev Yair Zaslavsky:
Keith summed things quite right as far as I know (I did not know about the range allocated to Qumranet) =20 From code perspective - We have a MacPoolManager infrastructure which holds a pool of Mac addresses, and per deletion of VM, the mac address is returned to the pool. =20
Which means that if you set up two oVirt systems independantly; one for production and one for testing, you will get collisions?
/Karli
From: "Keith Robertson" <kroberts@redhat.com> =20 =20 To: "Jonathan Horne" <jhorne@skopos.us> =20 =20 Cc: "users" <users@ovirt.org> =20 =20 Sent: Tuesday, January 8, 2013 5:15:04 AM =20 =20 Subject: Re: [Users] mac address re-use =20 =20
On 01/07/2013 05:22 PM, Jonathan Horne wrote: =20 =20
my 3.2 install seems to be reusing mac address of formerly-deleted guests. is this the normal behavior, and or can i turn this off? i would prefer to have a unique mac address for each new VM created. =20 =20 =20 thanks, =20 =20 =20 jonathan =20 =20 =20 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. =20 =20 =20
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users =20 =20 =20 I believe re-use is intentional. I suspect oVirt uses the IEEE [1] space allocated to Qumranet and that space is relatively small. There were previous discussions on the list regarding the probability of collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and because a program shouldn't just go randomly creating addresses from any available OUI block. =20 =20
Cheers, =20 =20 Keith=D7=9F =20 =20
[1] http://standards.ieee.org/develop/regauth/oui/public.html =20 =20
_______________________________________________ =20 =20 Users mailing list =20 =20 Users@ovirt.org =20 =20 http://lists.ovirt.org/mailman/listinfo/users =20 =20
<b>To: </b>"Yair Zaslavsky" <yzaslavs@redhat.com><br><b>Cc: </b>"Kei=
------=_Part_961824_554760252.1357627942039 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>You can always set a new range of mac addresses using= -<div><br></div><div><div>engine-config -g MacPoolRanges (to see the curre= nt range)</div><div><br></div><div>and then engine-config -s MacPoolRanges= =3D<new range></div><div><br></div><div><br></div><div><br></div><br>= <hr id=3D"zwchr"><blockquote style=3D"border-left:2px solid rgb(16, 16, 255= );margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style= :normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-si= ze:12pt;"><b>From: </b>"Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se><br= th Robertson" <kroberts@redhat.com>, "users" <users@ovirt.org><= br><b>Sent: </b>Tuesday, January 8, 2013 8:29:49 AM<br><b>Subject: </b>Re: = [Users] mac address re-use<br><br> tis 2013-01-08 klockan 01:18 -0500 skrev Yair Zaslavsky: <blockquote><font color=3D"#000000">Keith summed things quite right as far = as I know (I did not know about the range allocated to Qumranet)</font> </blockquote> <blockquote><font color=3D"#000000">From code perspective - We have a MacPo= olManager infrastructure which holds a pool of Mac addresses, and per delet= ion of VM, the mac address is returned to the pool.</font><br> </blockquote> Which means that if you set up two oVirt systems independantly; one for pro= duction and one for testing, you will get collisions?<br> <br> /Karli<br> <br> <blockquote><br> <br> </blockquote> <blockquote><br> <br> <hr align=3D"center"> <br> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Keith Robertson" <kroberts@redhat.com></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000">"Jonathan= Horne" <jhorne@skopos.us></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">"users" &= lt;users@ovirt.org></font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Tuesday= , January 8, 2013 5:15:04 AM</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] mac address re-use</font><br> <br> </blockquote> </blockquote> <blockquote> <blockquote><font color=3D"#000000">On 01/07/2013 05:22 PM, Jonathan Horne = wrote:</font><br> <br> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><font color=3D"#000000">my 3.2 install seems to be reusing mac = address of formerly-deleted guests. is this the normal behavior, and = or can i turn this off? i would prefer to have a unique mac address f= or each new VM created.</font> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><br> <br> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><font color=3D"#000000">thanks,</font> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><font color=3D"#000000">jonathan</font> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><br> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote><br> <hr align=3D"center"> <br> <font size=3D"1"><font color=3D"#bebebe">This is a PRIVATE message. If you = are not the intended recipient, please delete without copying and kindly ad= vise us by e-mail of the mistake in delivery. NOTE: Regardless of content, = this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written = agreement or government initiative expressly permitting the use of e-mail f= or such purpose.</font></font><font color=3D"#000000"> </font><br> <br> <pre><font color=3D"#000000">______________________________________________= _</font> <font color=3D"#000000">Users mailing list</font> <font color=3D"#000000"><a href=3D"mailto:Users@ovirt.org" target=3D"_blank= ">Users@ovirt.org</a></font> <font color=3D"#000000"><a href=3D"http://lists.ovirt.org/mailman/listinfo/= users" target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/users</a><= /font> </pre> </blockquote> <font color=3D"#000000">I believe re-use is intentional. I suspect oV= irt uses the IEEE [1] space allocated to Qumranet and that space is relativ= ely small. There were previous discussions on the list regarding the = probability of collisions/exhaustion, IIRC. In any case, you want re-use to prevent the possibility of exhaustion and = because a program shouldn't just go randomly creating addresses from any av= ailable OUI block.</font><br> <br> <font color=3D"#000000">Cheers,</font><br> <font color=3D"#000000">Keith=D7=9F</font><br> <br> <br> <br> <br> <font color=3D"#000000">[1] <a href=3D"http://standards.ieee.org/develop/re= gauth/oui/public.html" target=3D"_blank"> http://standards.ieee.org/develop/regauth/oui/public.html</a></font><br> <br> <font color=3D"#000000">_______________________________________________</fo= nt><br> <font color=3D"#000000">Users mailing list</font><br> <font color=3D"#000000">Users@ovirt.org</font><br> <font color=3D"#000000">http://lists.ovirt.org/mailman/listinfo/users</font=
<br> </blockquote> <br> <br> </blockquote> <br>
</blockquote><br></div></div></body></html> ------=_Part_961824_554760252.1357627942039--
On Tue, 8 Jan 2013 06:29:49 +0000 Karli Sjöberg <Karli.Sjoberg@slu.se> wrote:
tis 2013-01-08 klockan 01:18 -0500 skrev Yair Zaslavsky: Keith summed things quite right as far as I know (I did not know about the range allocated to Qumranet) From code perspective - We have a MacPoolManager infrastructure which holds a pool of Mac addresses, and per deletion of VM, the mac address is returned to the pool. Which means that if you set up two oVirt systems independantly; one for production and one for testing, you will get collisions?
^^^ No, VLANs please! If you need equal IP/ethernet setup while using 2 ovirt-engines, check VRF (OpenBSD can do it). jbelka
On 01/08/2013 08:29 AM, Karli Sjöberg wrote:
Which means that if you set up two oVirt systems independantly; one for production and one for testing, you will get collisions?
by default, the installer allocates a range of 255 mac addresses based on 2nd/3rd parts of engine ip address. so setting two engines on same 255.255.255.0 subnet requires to change the config to avoid mac conflicts.
Which means that if you set up two oVirt systems independantly; one for production and one for testing, you will get collisions?
/Karli If they are truly "independent" then they shd be on different subnets; hence, there shdn't be collisions. MAC addresses don't propagate beyond
On 01/08/2013 01:29 AM, Karli Sjöberg wrote: the router. Keith
participants (6)
-
Itamar Heim -
Jiri Belka -
Jonathan Horne -
Karli Sjöberg -
Keith Robertson -
Yair Zaslavsky