5:22 p.m.
--_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(a)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_--
10:15 p.m.
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(a)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://...
</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"...
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>
--------------040105080202010608020001--
1:18 a.m.
------=_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(a)redhat.com>
To: "Jonathan Horne" <jhorne(a)skopos.us>
Cc: "users" <users(a)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(a)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
_______________________________________________
Users mailing list
Users(a)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" &lt;kroberts(a)redhat.com&gt;<br><b>To:
</b>"Jonathan Horne" <jho=
rne(a)skopos.us&gt;<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(a)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/o...
/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--
1:29 a.m.
--_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_--
1:52 a.m.
------=_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(a)slu.se>
To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
Cc: "Keith Robertson" <kroberts(a)redhat.com>, "users"
<users(a)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(a)redhat.com>
>=20
=20
> > To: "Jonathan Horne" <jhorne(a)skopos.us>
>=20
=20
> > Cc: "users" <users(a)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(a)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(a)ovirt.org
>=20
=20
> > http://lists.ovirt.org/mailman/listinfo/users
>=20
=20
------=_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"
&lt;Karli.Sjoberg(a)slu.se&gt;<br=
<b>To: </b>"Yair Zaslavsky"
&lt;yzaslavs(a)redhat.com&gt;<br><b>Cc: </b>"Kei=
th
Robertson" &lt;kroberts(a)redhat.com&gt;, "users"
&lt;users(a)ovirt.org&gt;<=
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" &lt;kroberts(a)redhat.com&gt;</font<br>
<b><font color=3D"#000000">To:
</font></b><font color=3D"#000000">"Jonathan=
Horne" &lt;jhorne(a)skopos.us&gt;</font<br>
<b><font color=3D"#000000">Cc: </font></b><font
color=3D"#000000">"users" &=
lt;users(a)ovirt.org&gt;</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(a)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/us...
/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(a)ovirt.org</font<br>
<font
color=3D"#000000">http://lists.ovirt.org/mailman/listinfo/us...
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote><br></div></div></body></html>
------=_Part_961824_554760252.1357627942039--
3:49 a.m.
On Tue, 8 Jan 2013 06:29:49 +0000
Karli Sjöberg <Karli.Sjoberg(a)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
4:35 a.m.
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.
7:14 a.m.
On 01/08/2013 01: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?
/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
the router.
Keith
4371
days inactive
4372
days old
7 comments
6 participants
participants (6)
-
Itamar Heim -
Jiri Belka -
Jonathan Horne -
Karli Sjöberg -
Keith Robertson -
Yair Zaslavsky