12:13 a.m.
------=_Part_14223209_123477223.1360131191449
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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 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 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.
Regards,
Mike
------=_Part_14223209_123477223.1360131191449
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'>Hi,<br><br>The current situation dictates that if
the=
configuration value AllowDuplicateMacAddresses <br>is set to false (this i=
s the default setting), then we block import or switching snapshots where<b=
r>a MAC address in one or more of the snapshot/ovf's virtual NICs is alread=
y used.<br><br>Given that we don't currently give the admin any option to
s=
elect otherwise, I'm not sure <br>that's a very robust
behaviour..<br>First=
of all the MAC address should be unique per network and not in the whole s=
ystem (like<br>it is currently).<br>Furthermore, as long as in the same net=
work there are no two virtual NICs running with the <br>same address, it is=
not such a bad situation.<br><br>Therefore, I would like to propose a coup=
le of solutions (from backend perspective):<br> 1. Keep
blocking.<br>=
2. Keep blocking but fix the mac pools to be per network
basis.<br>&=
nbsp; 3. Don't block, and allow duplicate MACs in these scenarios, but bloc=
k on activating a NIC <br> with
duplicate MAC=
address. Warn the user that the NIC is with duplicate MAC, and
<br> &=
nbsp; perhaps even unplug or unwire it so that it would b=
e obvious that it's using someone
else's<br> =
MAC.<br> 4. Don't block, and give the problematic NIC a new MAC from
=
the pool.<br><br>Solution 1 is obviously not the greatest (hence this email=
).<br>In my opinion, 4 is sort of a cat in a bag, since I'm not sure changi=
ng the HWADDR for the<br>guest OS is really a good idea.<br>Solution 2 woul=
d be nice going forward, but it just reduces the chances of an admin to com=
e<br>across this situation and doesn't solve it entirely.<br>Hence, I
would=
favour solution 3 which seems to solve the problem and allow the admin to<=
br>choose what to do.<br><br>Please voice your opinion, or propose an
alter=
nate solution.<br><br><div><span
name=3D"x"></span>Regards,<br>Mike<span na=
me=3D"x"></span><br></div><br></div></body></html>
------=_Part_14223209_123477223.1360131191449--
6:21 a.m.
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "engine-devel" <engine-devel(a)ovirt.org>
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 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
6:19 a.m.
On 07/02/2013 14:21, Muli Salem wrote:
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "engine-devel" <engine-devel(a)ovirt.org>
> 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 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
4:15 p.m.
On 02/08/2013 02:19 PM, Itamar Heim wrote:
On 07/02/2013 14:21, Muli Salem wrote:
>
>
> ----- Original Message -----
>> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
>> To: "engine-devel" <engine-devel(a)ovirt.org>
>> 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
12:24 a.m.
----- 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" <mkolesni(a)redhat.com>
>>> To: "engine-devel" <engine-devel(a)ovirt.org>
>>> 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
>>>
>>>
12:42 a.m.
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" <mkolesni(a)redhat.com>
>>>> To: "engine-devel" <engine-devel(a)ovirt.org>
>>>> 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
>>>>
>>>>
4091
days inactive
4095
days old
5 comments
4 participants
participants (4)
-
Itamar Heim -
Mike Kolesnik -
Moti Asayag -
Muli Salem