Bug #4992

OpenNebula does not take into account VM NIC MAC value

Added by Alvaro Simon over 4 years ago. Updated over 3 years ago.

Status:PendingStart date:01/23/2017
Priority:HighDue date:
Assignee:Juan Jose Montiel Cano% Done:


Category:Core & System
Target version:Release 5.4.4
Resolution: Pull request:
Affected Versions:OpenNebula 5.2


Dear OpenNebula developers

We have found that in the latest ONE version if you ask for a specific MAC and IP in your VM template within NIC section, as example:

NIC = [
  IP = "",
  MAC = "AA:01:01:01:01:01",
  MODEL = "virtio",
  NETWORK = "network-red",
  NETWORK_UNAME = "oneadmin" ]

But you have for some reason several ARs in your VNET network with the same IP but different MACs, OpenNebula does not use the correct one, it seems that first gets the AR with lower id (the MAC request is not taken in to account only the IP matches). So the onevm info differs from the original template and looks like this:


ETH0_MAC is gathered from a different AR (that also exists). Also from VNET leases we can check that is used the wrong AR.

I think that we didn't have this issue before, could you please take a look?

Cheers and thanks!


#1 Updated by John Noss over 4 years ago

To add a note on this -- we have also run into this issue; what we do as a workaround is just hold the IP on the AR that has the MAC we don't want, and then create a new AR (size of 1) at the IP we want with the mac we want. This way the only AR that has the IP available when we instantiate the VM is the one with the MAC that we want. I agree it would be nice to have OpenNebula automatically select the right AR (by taking the MAC requested in the VM template into account). Also this workaround requires you to hold the IP first, then create the new AR of size 1 - this wouldn't work if there were pre-existing ARs with different mac starts, as holding an IP holds it on all ARs that contain that IP -- it doesn't seem to be possible to hold IPs on a specific AR.

As a followup, it would also be nice if OpenNebula would block that IP from being handed out on the other ARs -- we've discovered that it's possible to generate an IP conflict due to the overlapping ARs. As long as noone clicks release on the IP on the other AR, it's fine, but, it would be nice if OpenNebula would only select an IP if it was not in use in any AR -- ie, for these overlapping ARs, they should be mutually exclusive - an IP should only be allowed to be in use on one AR.

Let me know if that makes sense or I can explain more,

#2 Updated by Alvaro Simon over 4 years ago

yes I agree on that, OpenNebula should use some kind of matchmaking algorithm to detect the requested AR features from the VM template and find (if it is possible) the correct AR from the VNET. That will be very useful for some use cases.
The question is if there are several potential ARs that could match with your request, what to do in that case... choose the lower id or just display an error about the AR ambiguity.

#3 Updated by Juan Jose Montiel Cano almost 4 years ago

  • Assignee set to Juan Jose Montiel Cano
  • Target version set to Release 5.4.1

In the new version of OpenNebula (5.4.1), you can not enter IP and MAC ,at the same time, within NIC section.

Related commit: ba40cffd

#4 Updated by Alvaro Simon almost 4 years ago

Dear Juan

I'm a bit confused right now, I think that this thread https://forum.opennebula.org/t/opennebula-5-4-0-is-not-able-to-find-mac-ip-lease-from-vnet/4923 is also related with this issue. That means that now we are not able to ask for and IP and MAC within NIC section? that will break the backwards compatibility with the current templates.

Also the system does not complains if you add the same IP with different MACs, as example:

  1. cat vnet1.template
    AR = [
    TYPE = "IP4",
    IP = "",
    MAC = "aa:01:01:01:01:28",
    QUATTOR = "1",
    HOSTNAME = "testme",
    SIZE = "1"
  1. cat vnet2.template
    AR = [
    TYPE = "IP4",
    IP = "",
    MAC = "aa:01:01:01:01:29",
    QUATTOR = "1",
    HOSTNAME = "testme",
    SIZE = "1"

and actually I do not get any error message adding these ARs to the same VNET in 5.4.0:

  1. onevnet addar 4 vnet1.template
  2. onevnet addar 4 vnet2.template


  1. onevnet show 4
    AR 213
    SIZE : 1
    LEASES : 0

MAC aa:01:01:01:01:28 aa:01:01:01:01:28

AR 214
SIZE : 1

MAC aa:01:01:01:01:29 aa:01:01:01:01:29

So if you do not allow to ask for an IP and MAC that could be a problem. Maybe you should include an options to allow (or not) IPs or MAC overlapping. If you allow IPs and MACs overlapping you should keep the MAC/IP request into the VM NIC section.


#5 Updated by Ruben S. Montero over 3 years ago

  • Target version changed from Release 5.4.1 to Release 5.4.3

#6 Updated by Ruben S. Montero over 3 years ago

  • Target version changed from Release 5.4.3 to Release 5.4.4

Also available in: Atom PDF