From mkolesni at redhat.com Wed Feb 6 01:13:11 2013 Content-Type: multipart/mixed; boundary="===============5561758136993017446==" MIME-Version: 1.0 From: Mike Kolesnik To: devel at ovirt.org Subject: [Engine-devel] Import/snapshots duplicate MAC support Date: Wed, 06 Feb 2013 01:13:11 -0500 Message-ID: <812483959.14223210.1360131191449.JavaMail.root@redhat.com> In-Reply-To: 1254116832.14221314.1360130333346.JavaMail.root@redhat.com --===============5561758136993017446== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_14223209_123477223.1360131191449 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Hi, = The current situation dictates that if the configuration value AllowDuplica= teMacAddresses = is set to false (this is the default setting), then we block import or swit= ching snapshots where = a MAC address in one or more of the snapshot/ovf's virtual NICs is already = used. = Given that we don't currently give the admin any option to select otherwise= , I'm not sure = that's a very robust behaviour.. = First of all the MAC address should be unique per network and not in the wh= ole system (like = it is currently). = Furthermore, as long as in the same network there are no two virtual NIC s = running with the = same address, it is not such a bad situation. = Therefore, I would like to propose a couple of solutions (from backend pers= pective): = 1. Keep blocking. = 2. Keep blocking but fix the mac pools to be per network basis. = 3. Don't block, and allow duplicate MACs in these scenarios, but block on a= ctivating a NIC = with duplicate MAC address. Warn the user that the NIC is with duplicate MA= C, and = perhaps even unplug or unwire it so that it would be obvious that it's usin= g someone else's = MAC. = 4. Don't block, and give the problematic NIC a new MAC from the pool. = Solution 1 is obviously not the greatest (hence this email). = In my opinion, 4 is sort of a cat in a bag, since I'm not sure changing the= HWADDR for the = guest OS is really a good idea. = Solution 2 would be nice going forward, but it just reduces the chances of = an admin to come = across this situation and doesn't solve it entirely. = Hence, I would favour solution 3 which seems to solve the problem and allow= the admin to = choose what to do. = Please voice your opinion, or propose an alternate solution. = Regards, = Mike = ------=3D_Part_14223209_123477223.1360131191449 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable <=3D div style=3D3D'font-family: times new roman,new york,times,serif; font-size= : =3D 12pt; color: #000000'>Hi,

The current situation dictates that if the= =3D configuration value AllowDuplicateMacAddresses
is set to false (this i= =3D s the default setting), then we block import or switching snapshots wherea MAC address in one or more of the snapshot/ovf's virtual NICs is alread= =3D y used.

Given that we don't currently give the admin any option to s= =3D elect otherwise, I'm not sure
that's a very robust behaviour..
First= =3D of all the MAC address should be unique per network and not in the whole s= =3D ystem (like
it is currently).
Furthermore, as long as in the same net= =3D work there are no two virtual NICs running with the
same address, it is= =3D not such a bad situation.

Therefore, I would like to propose a coup= =3D le of solutions (from backend perspective):
  1. Keep blocking.
= =3D   2. Keep blocking but fix the mac pools to be per network basis.
&= =3D nbsp; 3. Don't block, and allow duplicate MACs in these scenarios, but bloc= =3D k on activating a NIC
      with duplicate MAC= =3D address. Warn the user that the NIC is with duplicate MAC, and
 &= =3D nbsp;    perhaps even unplug or unwire it so that it would b= =3D e obvious that it's using someone else's
      = =3D MAC.
  4. Don't block, and give the problematic NIC a new MAC from = =3D the pool.

Solution 1 is obviously not the greatest (hence this email= =3D ).
In my opinion, 4 is sort of a cat in a bag, since I'm not sure changi= =3D ng the HWADDR for the
guest OS is really a good idea.
Solution 2 woul= =3D d be nice going forward, but it just reduces the chances of an admin to com= =3D e
across this situation and doesn't solve it entirely.
Hence, I would= =3D favour solution 3 which seems to solve the problem and allow the admin to<= =3D br>choose what to do.

Please voice your opinion, or propose an alter= =3D nate solution.

Regards,
Mike

------=3D_Part_14223209_123477223.1360131191449-- --===============5561758136993017446== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzE0MjIzMjA5XzEyMzQ3NzIyMy4xMzYwMTMxMTkxNDQ5CkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3 Yml0CgpIaSwgCgpUaGUgY3VycmVudCBzaXR1YXRpb24gZGljdGF0ZXMgdGhhdCBpZiB0aGUgY29u ZmlndXJhdGlvbiB2YWx1ZSBBbGxvd0R1cGxpY2F0ZU1hY0FkZHJlc3NlcyAKaXMgc2V0IHRvIGZh bHNlICh0aGlzIGlzIHRoZSBkZWZhdWx0IHNldHRpbmcpLCB0aGVuIHdlIGJsb2NrIGltcG9ydCBv ciBzd2l0Y2hpbmcgc25hcHNob3RzIHdoZXJlIAphIE1BQyBhZGRyZXNzIGluIG9uZSBvciBtb3Jl IG9mIHRoZSBzbmFwc2hvdC9vdmYncyB2aXJ0dWFsIE5JQ3MgaXMgYWxyZWFkeSB1c2VkLiAKCkdp dmVuIHRoYXQgd2UgZG9uJ3QgY3VycmVudGx5IGdpdmUgdGhlIGFkbWluIGFueSBvcHRpb24gdG8g c2VsZWN0IG90aGVyd2lzZSwgSSdtIG5vdCBzdXJlIAp0aGF0J3MgYSB2ZXJ5IHJvYnVzdCBiZWhh dmlvdXIuLiAKRmlyc3Qgb2YgYWxsIHRoZSBNQUMgYWRkcmVzcyBzaG91bGQgYmUgdW5pcXVlIHBl ciBuZXR3b3JrIGFuZCBub3QgaW4gdGhlIHdob2xlIHN5c3RlbSAobGlrZSAKaXQgaXMgY3VycmVu dGx5KS4gCkZ1cnRoZXJtb3JlLCBhcyBsb25nIGFzIGluIHRoZSBzYW1lIG5ldHdvcmsgdGhlcmUg YXJlIG5vIHR3byB2aXJ0dWFsIE5JQyBzIHJ1bm5pbmcgd2l0aCB0aGUgCnNhbWUgYWRkcmVzcywg aXQgaXMgbm90IHN1Y2ggYSBiYWQgc2l0dWF0aW9uLiAKClRoZXJlZm9yZSwgSSB3b3VsZCBsaWtl IHRvIHByb3Bvc2UgYSBjb3VwbGUgb2Ygc29sdXRpb25zIChmcm9tIGJhY2tlbmQgcGVyc3BlY3Rp dmUpOiAKMS4gS2VlcCBibG9ja2luZy4gCjIuIEtlZXAgYmxvY2tpbmcgYnV0IGZpeCB0aGUgbWFj IHBvb2xzIHRvIGJlIHBlciBuZXR3b3JrIGJhc2lzLiAKMy4gRG9uJ3QgYmxvY2ssIGFuZCBhbGxv dyBkdXBsaWNhdGUgTUFDcyBpbiB0aGVzZSBzY2VuYXJpb3MsIGJ1dCBibG9jayBvbiBhY3RpdmF0 aW5nIGEgTklDIAp3aXRoIGR1cGxpY2F0ZSBNQUMgYWRkcmVzcy4gV2FybiB0aGUgdXNlciB0aGF0 IHRoZSBOSUMgaXMgd2l0aCBkdXBsaWNhdGUgTUFDLCBhbmQgCnBlcmhhcHMgZXZlbiB1bnBsdWcg b3IgdW53aXJlIGl0IHNvIHRoYXQgaXQgd291bGQgYmUgb2J2aW91cyB0aGF0IGl0J3MgdXNpbmcg c29tZW9uZSBlbHNlJ3MgCk1BQy4gCjQuIERvbid0IGJsb2NrLCBhbmQgZ2l2ZSB0aGUgcHJvYmxl bWF0aWMgTklDIGEgbmV3IE1BQyBmcm9tIHRoZSBwb29sLiAKClNvbHV0aW9uIDEgaXMgb2J2aW91 c2x5IG5vdCB0aGUgZ3JlYXRlc3QgKGhlbmNlIHRoaXMgZW1haWwpLiAKSW4gbXkgb3Bpbmlvbiwg NCBpcyBzb3J0IG9mIGEgY2F0IGluIGEgYmFnLCBzaW5jZSBJJ20gbm90IHN1cmUgY2hhbmdpbmcg dGhlIEhXQUREUiBmb3IgdGhlIApndWVzdCBPUyBpcyByZWFsbHkgYSBnb29kIGlkZWEuIApTb2x1 dGlvbiAyIHdvdWxkIGJlIG5pY2UgZ29pbmcgZm9yd2FyZCwgYnV0IGl0IGp1c3QgcmVkdWNlcyB0 aGUgY2hhbmNlcyBvZiBhbiBhZG1pbiB0byBjb21lIAphY3Jvc3MgdGhpcyBzaXR1YXRpb24gYW5k IGRvZXNuJ3Qgc29sdmUgaXQgZW50aXJlbHkuIApIZW5jZSwgSSB3b3VsZCBmYXZvdXIgc29sdXRp b24gMyB3aGljaCBzZWVtcyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgYWxsb3cgdGhlIGFkbWlu IHRvIApjaG9vc2Ugd2hhdCB0byBkby4gCgpQbGVhc2Ugdm9pY2UgeW91ciBvcGluaW9uLCBvciBw cm9wb3NlIGFuIGFsdGVybmF0ZSBzb2x1dGlvbi4gCgoKUmVnYXJkcywgCk1pa2UgCgoKLS0tLS0t PV9QYXJ0XzE0MjIzMjA5XzEyMzQ3NzIyMy4xMzYwMTMxMTkxNDQ5CkNvbnRlbnQtVHlwZTogdGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1w cmludGFibGUKCjxodG1sPjxoZWFkPjxzdHlsZSB0eXBlPTNEJ3RleHQvY3NzJz5wIHsgbWFyZ2lu OiAwOyB9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PD0KZGl2IHN0eWxlPTNEJ2ZvbnQtZmFtaWx5OiB0 aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7IGZvbnQtc2l6ZTogPQoxMnB0OyBj b2xvcjogIzAwMDAwMCc+SGksPGJyPjxicj5UaGUgY3VycmVudCBzaXR1YXRpb24gZGljdGF0ZXMg dGhhdCBpZiB0aGU9CiBjb25maWd1cmF0aW9uIHZhbHVlIEFsbG93RHVwbGljYXRlTWFjQWRkcmVz c2VzIDxicj5pcyBzZXQgdG8gZmFsc2UgKHRoaXMgaT0KcyB0aGUgZGVmYXVsdCBzZXR0aW5nKSwg dGhlbiB3ZSBibG9jayBpbXBvcnQgb3Igc3dpdGNoaW5nIHNuYXBzaG90cyB3aGVyZTxiPQpyPmEg TUFDIGFkZHJlc3MgaW4gb25lIG9yIG1vcmUgb2YgdGhlIHNuYXBzaG90L292ZidzIHZpcnR1YWwg TklDcyBpcyBhbHJlYWQ9CnkgdXNlZC48YnI+PGJyPkdpdmVuIHRoYXQgd2UgZG9uJ3QgY3VycmVu dGx5IGdpdmUgdGhlIGFkbWluIGFueSBvcHRpb24gdG8gcz0KZWxlY3Qgb3RoZXJ3aXNlLCBJJ20g bm90IHN1cmUgPGJyPnRoYXQncyBhIHZlcnkgcm9idXN0IGJlaGF2aW91ci4uPGJyPkZpcnN0PQog b2YgYWxsIHRoZSBNQUMgYWRkcmVzcyBzaG91bGQgYmUgdW5pcXVlIHBlciBuZXR3b3JrIGFuZCBu b3QgaW4gdGhlIHdob2xlIHM9CnlzdGVtIChsaWtlPGJyPml0IGlzIGN1cnJlbnRseSkuPGJyPkZ1 cnRoZXJtb3JlLCBhcyBsb25nIGFzIGluIHRoZSBzYW1lIG5ldD0Kd29yayB0aGVyZSBhcmUgbm8g dHdvIHZpcnR1YWwgTklDcyBydW5uaW5nIHdpdGggdGhlIDxicj5zYW1lIGFkZHJlc3MsIGl0IGlz PQogbm90IHN1Y2ggYSBiYWQgc2l0dWF0aW9uLjxicj48YnI+VGhlcmVmb3JlLCBJIHdvdWxkIGxp a2UgdG8gcHJvcG9zZSBhIGNvdXA9CmxlIG9mIHNvbHV0aW9ucyAoZnJvbSBiYWNrZW5kIHBlcnNw ZWN0aXZlKTo8YnI+Jm5ic3A7IDEuIEtlZXAgYmxvY2tpbmcuPGJyPj0KJm5ic3A7IDIuIEtlZXAg YmxvY2tpbmcgYnV0IGZpeCB0aGUgbWFjIHBvb2xzIHRvIGJlIHBlciBuZXR3b3JrIGJhc2lzLjxi cj4mPQpuYnNwOyAzLiBEb24ndCBibG9jaywgYW5kIGFsbG93IGR1cGxpY2F0ZSBNQUNzIGluIHRo ZXNlIHNjZW5hcmlvcywgYnV0IGJsb2M9Cmsgb24gYWN0aXZhdGluZyBhIE5JQyA8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggZHVwbGljYXRlIE1BQz0KIGFkZHJlc3MuIFdh cm4gdGhlIHVzZXIgdGhhdCB0aGUgTklDIGlzIHdpdGggZHVwbGljYXRlIE1BQywgYW5kIDxicj4m bmJzcDsmPQpuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJoYXBzIGV2ZW4gdW5wbHVnIG9yIHVu d2lyZSBpdCBzbyB0aGF0IGl0IHdvdWxkIGI9CmUgb2J2aW91cyB0aGF0IGl0J3MgdXNpbmcgc29t ZW9uZSBlbHNlJ3M8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0KTUFDLjxicj4m bmJzcDsgNC4gRG9uJ3QgYmxvY2ssIGFuZCBnaXZlIHRoZSBwcm9ibGVtYXRpYyBOSUMgYSBuZXcg TUFDIGZyb20gPQp0aGUgcG9vbC48YnI+PGJyPlNvbHV0aW9uIDEgaXMgb2J2aW91c2x5IG5vdCB0 aGUgZ3JlYXRlc3QgKGhlbmNlIHRoaXMgZW1haWw9CikuPGJyPkluIG15IG9waW5pb24sIDQgaXMg c29ydCBvZiBhIGNhdCBpbiBhIGJhZywgc2luY2UgSSdtIG5vdCBzdXJlIGNoYW5naT0KbmcgdGhl IEhXQUREUiBmb3IgdGhlPGJyPmd1ZXN0IE9TIGlzIHJlYWxseSBhIGdvb2QgaWRlYS48YnI+U29s dXRpb24gMiB3b3VsPQpkIGJlIG5pY2UgZ29pbmcgZm9yd2FyZCwgYnV0IGl0IGp1c3QgcmVkdWNl cyB0aGUgY2hhbmNlcyBvZiBhbiBhZG1pbiB0byBjb209CmU8YnI+YWNyb3NzIHRoaXMgc2l0dWF0 aW9uIGFuZCBkb2Vzbid0IHNvbHZlIGl0IGVudGlyZWx5Ljxicj5IZW5jZSwgSSB3b3VsZD0KIGZh dm91ciBzb2x1dGlvbiAzIHdoaWNoIHNlZW1zIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGFuZCBhbGxv dyB0aGUgYWRtaW4gdG88PQpicj5jaG9vc2Ugd2hhdCB0byBkby48YnI+PGJyPlBsZWFzZSB2b2lj ZSB5b3VyIG9waW5pb24sIG9yIHByb3Bvc2UgYW4gYWx0ZXI9Cm5hdGUgc29sdXRpb24uPGJyPjxi cj48ZGl2PjxzcGFuIG5hbWU9M0QieCI+PC9zcGFuPlJlZ2FyZHMsPGJyPk1pa2U8c3BhbiBuYT0K bWU9M0QieCI+PC9zcGFuPjxicj48L2Rpdj48YnI+PC9kaXY+PC9ib2R5PjwvaHRtbD4KLS0tLS0t PV9QYXJ0XzE0MjIzMjA5XzEyMzQ3NzIyMy4xMzYwMTMxMTkxNDQ5LS0K --===============5561758136993017446==-- From msalem at redhat.com Thu Feb 7 07:21:24 2013 Content-Type: multipart/mixed; boundary="===============1348683571606641561==" MIME-Version: 1.0 From: Muli Salem To: devel at ovirt.org Subject: Re: [Engine-devel] Import/snapshots duplicate MAC support Date: Thu, 07 Feb 2013 07:21:24 -0500 Message-ID: <11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> In-Reply-To: 812483959.14223210.1360131191449.JavaMail.root@redhat.com --===============1348683571606641561== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Sent: Wednesday, 6 February, 2013 8:13:11 AM > Subject: [Engine-devel] Import/snapshots duplicate MAC support > = > = > = > Hi, > = > The current situation dictates that if the configuration value > AllowDuplicateMacAddresses > is set to false (this is the default setting), then we block import > or switching snapshots where > a MAC address in one or more of the snapshot/ovf's virtual NICs is > already used. > = > Given that we don't currently give the admin any option to select > otherwise, I'm not sure > that's a very robust behaviour.. > First of all the MAC address should be unique per network and not in > the whole system (like > it is currently). > Furthermore, as long as in the same network there are no two virtual > NICs running with the > same address, it is not such a bad situation. > = > Therefore, I would like to propose a couple of solutions (from > backend perspective): > 1. Keep blocking. > 2. Keep blocking but fix the mac pools to be per network basis. > 3. Don't block, and allow duplicate MACs in these scenarios, but > block on activating a NIC > with duplicate MAC address. Warn the user that the NIC is with > duplicate MAC, and > perhaps even unplug or unwire it so that it would be obvious that > it's using someone else's > MAC. > 4. Don't block, and give the problematic NIC a new MAC from the pool. > = > Solution 1 is obviously not the greatest (hence this email). > In my opinion, 4 is sort of a cat in a bag, since I'm not sure > changing the HWADDR for the > guest OS is really a good idea. > Solution 2 would be nice going forward, but it just reduces the > chances of an admin to come > across this situation and doesn't solve it entirely. > Hence, I would favour solution 3 which seems to solve the problem and > allow the admin to > choose what to do. > = > Please voice your opinion, or propose an alternate solution. Another solution would be to perform the action without adding the problema= tic vNic, and notify the user about it. Overall, I am in favor of solution 3 as well. > = > = > Regards, > Mike > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============1348683571606641561==-- From iheim at redhat.com Fri Feb 8 14:19:11 2013 Content-Type: multipart/mixed; boundary="===============5013789984999804041==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Import/snapshots duplicate MAC support Date: Fri, 08 Feb 2013 14:19:31 +0200 Message-ID: <5114ED53.9010900@redhat.com> In-Reply-To: 11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com --===============5013789984999804041== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/02/2013 14:21, Muli Salem wrote: > > > ----- Original Message ----- >> From: "Mike Kolesnik" >> To: "engine-devel" >> Sent: Wednesday, 6 February, 2013 8:13:11 AM >> Subject: [Engine-devel] Import/snapshots duplicate MAC support >> >> >> >> Hi, >> >> The current situation dictates that if the configuration value >> AllowDuplicateMacAddresses >> is set to false (this is the default setting), then we block import >> or switching snapshots where >> a MAC address in one or more of the snapshot/ovf's virtual NICs is >> already used. >> >> Given that we don't currently give the admin any option to select >> otherwise, I'm not sure >> that's a very robust behaviour.. >> First of all the MAC address should be unique per network and not in >> the whole system (like >> it is currently). >> Furthermore, as long as in the same network there are no two virtual >> NICs running with the >> same address, it is not such a bad situation. >> >> Therefore, I would like to propose a couple of solutions (from >> backend perspective): >> 1. Keep blocking. >> 2. Keep blocking but fix the mac pools to be per network basis. mac pools per network are a good feature, but i would still warn on = duplicates. mac's in general are supposed to be unique in a DC, not only = in a single layer 2 network (i.e., one checking a switch mac table isn't = expecting to find different sources for the same mac address). so +1 for the feature, but -1 as solution for this problem. >> 3. Don't block, and allow duplicate MACs in these scenarios, but >> block on activating a NIC >> with duplicate MAC address. Warn the user that the NIC is with >> duplicate MAC, and >> perhaps even unplug or unwire it so that it would be obvious that >> it's using someone else's >> MAC. +1 on importing in unplug mode and enabling this check on plugging even better if we could detect at import time with candoaction and let = user choose if to 'generate new mac'. >> 4. Don't block, and give the problematic NIC a new MAC from the pool. >> >> Solution 1 is obviously not the greatest (hence this email). >> In my opinion, 4 is sort of a cat in a bag, since I'm not sure >> changing the HWADDR for the >> guest OS is really a good idea. >> Solution 2 would be nice going forward, but it just reduces the >> chances of an admin to come >> across this situation and doesn't solve it entirely. >> Hence, I would favour solution 3 which seems to solve the problem and >> allow the admin to >> choose what to do. >> >> Please voice your opinion, or propose an alternate solution. > > Another solution would be to perform the action without adding the proble= matic vNic, and notify the user about it. > > Overall, I am in favor of solution 3 as well. > >> >> >> Regards, >> Mike >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > --===============5013789984999804041==-- From masayag at redhat.com Sat Feb 9 17:15:08 2013 Content-Type: multipart/mixed; boundary="===============9003281368404526239==" MIME-Version: 1.0 From: Moti Asayag To: devel at ovirt.org Subject: Re: [Engine-devel] Import/snapshots duplicate MAC support Date: Sun, 10 Feb 2013 00:15:05 +0200 Message-ID: <5116CA69.3040405@redhat.com> In-Reply-To: 5114ED53.9010900@redhat.com --===============9003281368404526239== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/08/2013 02:19 PM, Itamar Heim wrote: > On 07/02/2013 14:21, Muli Salem wrote: >> >> >> ----- Original Message ----- >>> From: "Mike Kolesnik" >>> To: "engine-devel" >>> Sent: Wednesday, 6 February, 2013 8:13:11 AM >>> Subject: [Engine-devel] Import/snapshots duplicate MAC support >>> >>> >>> >>> Hi, >>> >>> The current situation dictates that if the configuration value >>> AllowDuplicateMacAddresses >>> is set to false (this is the default setting), then we block import >>> or switching snapshots where >>> a MAC address in one or more of the snapshot/ovf's virtual NICs is >>> already used. >>> >>> Given that we don't currently give the admin any option to select >>> otherwise, I'm not sure >>> that's a very robust behaviour.. >>> First of all the MAC address should be unique per network and not in >>> the whole system (like >>> it is currently). >>> Furthermore, as long as in the same network there are no two virtual >>> NICs running with the >>> same address, it is not such a bad situation. >>> >>> Therefore, I would like to propose a couple of solutions (from >>> backend perspective): >>> 1. Keep blocking. >>> 2. Keep blocking but fix the mac pools to be per network basis. > = > mac pools per network are a good feature, but i would still warn on > duplicates. mac's in general are supposed to be unique in a DC, not only > in a single layer 2 network (i.e., one checking a switch mac table isn't > expecting to find different sources for the same mac address). > = > so +1 for the feature, but -1 as solution for this problem. > = >>> 3. Don't block, and allow duplicate MACs in these scenarios, but >>> block on activating a NIC >>> with duplicate MAC address. Warn the user that the NIC is with >>> duplicate MAC, and >>> perhaps even unplug or unwire it so that it would be obvious that >>> it's using someone else's >>> MAC. > = > +1 on importing in unplug mode and enabling this check on plugging > even better if we could detect at import time with candoaction and let > user choose if to 'generate new mac'. > = I would go for introducing a new parameter to import vm action for allocating a new mac address if it is in use. Its default value should be set to false, so the user is aware of his intention to replace the vm's mac addresses. Else (if user decided vm should be imported with the exact mac addresses) block the operation on can-do-action with the list of mac addresses and the vm names which own them so the user can take different actions (e,g, free/replace these mac addresses). The user should be aware the change of import behaviour when the allow duplicate mac addresses is enabled. In which case even if the user asked not allocate new mac addresses for the taken one, the action will succeed. >>> 4. Don't block, and give the problematic NIC a new MAC from the pool. >>> >>> Solution 1 is obviously not the greatest (hence this email). >>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure >>> changing the HWADDR for the >>> guest OS is really a good idea. >>> Solution 2 would be nice going forward, but it just reduces the >>> chances of an admin to come >>> across this situation and doesn't solve it entirely. >>> Hence, I would favour solution 3 which seems to solve the problem and >>> allow the admin to >>> choose what to do. >>> >>> Please voice your opinion, or propose an alternate solution. >> >> Another solution would be to perform the action without adding the >> problematic vNic, and notify the user about it. >> >> Overall, I am in favor of solution 3 as well. >> >>> >>> >>> Regards, >>> Mike >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --===============9003281368404526239==-- From mkolesni at redhat.com Sun Feb 10 01:24:31 2013 Content-Type: multipart/mixed; boundary="===============0969169232774024003==" MIME-Version: 1.0 From: Mike Kolesnik To: devel at ovirt.org Subject: Re: [Engine-devel] Import/snapshots duplicate MAC support Date: Sun, 10 Feb 2013 01:24:30 -0500 Message-ID: <463090889.64926.1360477470932.JavaMail.root@redhat.com> In-Reply-To: 5116CA69.3040405@redhat.com --===============0969169232774024003== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > On 02/08/2013 02:19 PM, Itamar Heim wrote: > > On 07/02/2013 14:21, Muli Salem wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Mike Kolesnik" > >>> To: "engine-devel" > >>> Sent: Wednesday, 6 February, 2013 8:13:11 AM > >>> Subject: [Engine-devel] Import/snapshots duplicate MAC support > >>> > >>> > >>> > >>> Hi, > >>> > >>> The current situation dictates that if the configuration value > >>> AllowDuplicateMacAddresses > >>> is set to false (this is the default setting), then we block > >>> import > >>> or switching snapshots where > >>> a MAC address in one or more of the snapshot/ovf's virtual NICs > >>> is > >>> already used. > >>> > >>> Given that we don't currently give the admin any option to select > >>> otherwise, I'm not sure > >>> that's a very robust behaviour.. > >>> First of all the MAC address should be unique per network and not > >>> in > >>> the whole system (like > >>> it is currently). > >>> Furthermore, as long as in the same network there are no two > >>> virtual > >>> NICs running with the > >>> same address, it is not such a bad situation. > >>> > >>> Therefore, I would like to propose a couple of solutions (from > >>> backend perspective): > >>> 1. Keep blocking. > >>> 2. Keep blocking but fix the mac pools to be per network basis. > > = > > mac pools per network are a good feature, but i would still warn on > > duplicates. mac's in general are supposed to be unique in a DC, not > > only > > in a single layer 2 network (i.e., one checking a switch mac table > > isn't > > expecting to find different sources for the same mac address). > > = > > so +1 for the feature, but -1 as solution for this problem. > > = > >>> 3. Don't block, and allow duplicate MACs in these scenarios, but > >>> block on activating a NIC > >>> with duplicate MAC address. Warn the user that the NIC is with > >>> duplicate MAC, and > >>> perhaps even unplug or unwire it so that it would be obvious that > >>> it's using someone else's > >>> MAC. > > = > > +1 on importing in unplug mode and enabling this check on plugging > > even better if we could detect at import time with candoaction and > > let > > user choose if to 'generate new mac'. > > = > = > I would go for introducing a new parameter to import vm action for > allocating a new mac address if it is in use. Its default value > should > be set to false, so the user is aware of his intention to replace the > vm's mac addresses. Else (if user decided vm should be imported with > the > exact mac addresses) block the operation on can-do-action with the > list > of mac addresses and the vm names which own them so the user can take > different actions (e,g, free/replace these mac addresses). > = > The user should be aware the change of import behaviour when the > allow > duplicate mac addresses is enabled. In which case even if the user > asked > not allocate new mac addresses for the taken one, the action will > succeed. In this case, I would say that the default value should be the same as the "allow duplicate macs" option. If the user chose to override the default, then we should act according to his will.. This however solves only the import problem but not the snapshot switching problem, and in that case it's a bit more complicated to add a parameter.. It is the reason I initially opted for a "backend only" solution which can solve both cases. > = > >>> 4. Don't block, and give the problematic NIC a new MAC from the > >>> pool. > >>> > >>> Solution 1 is obviously not the greatest (hence this email). > >>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure > >>> changing the HWADDR for the > >>> guest OS is really a good idea. > >>> Solution 2 would be nice going forward, but it just reduces the > >>> chances of an admin to come > >>> across this situation and doesn't solve it entirely. > >>> Hence, I would favour solution 3 which seems to solve the problem > >>> and > >>> allow the admin to > >>> choose what to do. > >>> > >>> Please voice your opinion, or propose an alternate solution. > >> > >> Another solution would be to perform the action without adding the > >> problematic vNic, and notify the user about it. > >> > >> Overall, I am in favor of solution 3 as well. > >> > >>> > >>> > >>> Regards, > >>> Mike > >>> > >>> --===============0969169232774024003==-- From iheim at redhat.com Sun Feb 10 01:44:55 2013 Content-Type: multipart/mixed; boundary="===============1674190209594637184==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Import/snapshots duplicate MAC support Date: Sun, 10 Feb 2013 08:42:39 +0200 Message-ID: <5117415F.90003@redhat.com> In-Reply-To: 463090889.64926.1360477470932.JavaMail.root@redhat.com --===============1674190209594637184== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 10/02/2013 08:24, Mike Kolesnik wrote: > ----- Original Message ----- >> On 02/08/2013 02:19 PM, Itamar Heim wrote: >>> On 07/02/2013 14:21, Muli Salem wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Mike Kolesnik" >>>>> To: "engine-devel" >>>>> Sent: Wednesday, 6 February, 2013 8:13:11 AM >>>>> Subject: [Engine-devel] Import/snapshots duplicate MAC support >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> The current situation dictates that if the configuration value >>>>> AllowDuplicateMacAddresses >>>>> is set to false (this is the default setting), then we block >>>>> import >>>>> or switching snapshots where >>>>> a MAC address in one or more of the snapshot/ovf's virtual NICs >>>>> is >>>>> already used. >>>>> >>>>> Given that we don't currently give the admin any option to select >>>>> otherwise, I'm not sure >>>>> that's a very robust behaviour.. >>>>> First of all the MAC address should be unique per network and not >>>>> in >>>>> the whole system (like >>>>> it is currently). >>>>> Furthermore, as long as in the same network there are no two >>>>> virtual >>>>> NICs running with the >>>>> same address, it is not such a bad situation. >>>>> >>>>> Therefore, I would like to propose a couple of solutions (from >>>>> backend perspective): >>>>> 1. Keep blocking. >>>>> 2. Keep blocking but fix the mac pools to be per network basis. >>> >>> mac pools per network are a good feature, but i would still warn on >>> duplicates. mac's in general are supposed to be unique in a DC, not >>> only >>> in a single layer 2 network (i.e., one checking a switch mac table >>> isn't >>> expecting to find different sources for the same mac address). >>> >>> so +1 for the feature, but -1 as solution for this problem. >>> >>>>> 3. Don't block, and allow duplicate MACs in these scenarios, but >>>>> block on activating a NIC >>>>> with duplicate MAC address. Warn the user that the NIC is with >>>>> duplicate MAC, and >>>>> perhaps even unplug or unwire it so that it would be obvious that >>>>> it's using someone else's >>>>> MAC. >>> >>> +1 on importing in unplug mode and enabling this check on plugging >>> even better if we could detect at import time with candoaction and >>> let >>> user choose if to 'generate new mac'. >>> >> >> I would go for introducing a new parameter to import vm action for >> allocating a new mac address if it is in use. Its default value >> should >> be set to false, so the user is aware of his intention to replace the >> vm's mac addresses. Else (if user decided vm should be imported with >> the >> exact mac addresses) block the operation on can-do-action with the >> list >> of mac addresses and the vm names which own them so the user can take >> different actions (e,g, free/replace these mac addresses). >> >> The user should be aware the change of import behaviour when the >> allow >> duplicate mac addresses is enabled. In which case even if the user >> asked >> not allocate new mac addresses for the taken one, the action will >> succeed. > > In this case, I would say that the default value should be the same as the > "allow duplicate macs" option. > If the user chose to override the default, then we should act according to > his will.. I wouldn't make a default value change based on the config for this. = even for an environment that allows duplicate macs, it would be the = exception, not the rule. > > This however solves only the import problem but not the snapshot switching > problem, and in that case it's a bit more complicated to add a parameter.. > It is the reason I initially opted for a "backend only" solution which can > solve both cases. > >> >>>>> 4. Don't block, and give the problematic NIC a new MAC from the >>>>> pool. >>>>> >>>>> Solution 1 is obviously not the greatest (hence this email). >>>>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure >>>>> changing the HWADDR for the >>>>> guest OS is really a good idea. >>>>> Solution 2 would be nice going forward, but it just reduces the >>>>> chances of an admin to come >>>>> across this situation and doesn't solve it entirely. >>>>> Hence, I would favour solution 3 which seems to solve the problem >>>>> and >>>>> allow the admin to >>>>> choose what to do. >>>>> >>>>> Please voice your opinion, or propose an alternate solution. >>>> >>>> Another solution would be to perform the action without adding the >>>> problematic vNic, and notify the user about it. >>>> >>>> Overall, I am in favor of solution 3 as well. >>>> >>>>> >>>>> >>>>> Regards, >>>>> Mike >>>>> >>>>> --===============1674190209594637184==--