8: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--