Bug #4737

VN_MAD issue after switching to 5.0

Added by EOLE Team over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:08/23/2016
Priority:NormalDue date:
Assignee:Carlos Martín% Done:

0%

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

Description

Hello,

After our upgrade to 5.0 on our production infrastructure we find another issue: updating the networks VN_MAD.

If I understand correctly, before 5.0 it was set per host, now it's set per network.

But:

  • the hosts does not have the VN_MAD set
  • the network has the VN_MAD set (but not in the TEMPLATE part):
    <VNET>
      <ID>37</ID>
      <UID>4</UID>
      <GID>101</GID>
      <UNAME>jenkins</UNAME>
      <GNAME>mensr</GNAME>
      <NAME>academie</NAME>
      <PERMISSIONS>
        <OWNER_U>1</OWNER_U>
        <OWNER_M>1</OWNER_M>
        <OWNER_A>0</OWNER_A>
        <GROUP_U>0</GROUP_U>
        <GROUP_M>0</GROUP_M>
        <GROUP_A>0</GROUP_A>
        <OTHER_U>0</OTHER_U>
        <OTHER_M>0</OTHER_M>
        <OTHER_A>0</OTHER_A>
      </PERMISSIONS>
      <CLUSTERS>
        <ID>0</ID>
        <ID>100</ID>
      </CLUSTERS>
      <BRIDGE><![CDATA[nebula]]></BRIDGE>
      <PARENT_NETWORK_ID/>
      <VN_MAD><![CDATA[ovswitch]]></VN_MAD>
      <PHYDEV/>
      <VLAN_ID><![CDATA[39]]></VLAN_ID>
      <VLAN_ID_AUTOMATIC>1</VLAN_ID_AUTOMATIC>
      <USED_LEASES>1</USED_LEASES>
      <VROUTERS/>
      <TEMPLATE>
        <BRIDGE><![CDATA[nebula]]></BRIDGE>
        <PHYDEV><![CDATA[]]></PHYDEV>
        <PUBLIC><![CDATA[NO]]></PUBLIC>
        <SECURITY_GROUPS><![CDATA[0]]></SECURITY_GROUPS>
      </TEMPLATE>
      <AR_POOL>
        <AR>
          <AR_ID><![CDATA[0]]></AR_ID>
          <IP><![CDATA[192.168.0.100]]></IP>
          <MAC><![CDATA[02:00:c0:a8:00:64]]></MAC>
          <SIZE><![CDATA[154]]></SIZE>
          <TYPE><![CDATA[IP4]]></TYPE>
          <MAC_END><![CDATA[02:00:c0:a8:00:fd]]></MAC_END>
          <IP_END><![CDATA[192.168.0.253]]></IP_END>
          <USED_LEASES>1</USED_LEASES>
          <LEASES>
            <LEASE>
              <IP><![CDATA[192.168.0.184]]></IP>
              <MAC><![CDATA[02:00:c0:a8:00:b8]]></MAC>
              <VM><![CDATA[52894]]></VM>
            </LEASE>
          </LEASES>
        </AR>
      </AR_POOL>
    </VNET>
    
  • I can't make a reservation:
    [VirtualNetworkReserve] No VN_MAD in template for Virtual Network.
    
  • the VMs are deployed with the good network driver:
    Mon Aug 22 14:12:42 2016 [Z0][VMM][I]: Successfully execute virtualization driver operation: deploy.
    Mon Aug 22 14:12:43 2016 [Z0][VMM][I]: post: Executed "sudo ovs-vsctl set Port one-52742-1 tag=39".
    
  • Sunstone does not show the VN_MAD attribute (see network-without-vn_mad.png)
  • Sunstone update modal display wrong information (see network-update-without-vn_mad.png)

So, I think the problem is either:

  1. in Sunstone which should use the VNET/VN_MAD attribute instead of VNET/TEMPLATE/VN_MAD
  2. in the upgrade process which should define the VNET/TEMPLATE/VN_MAD in addition to VNET/VN_MAD

The second looks strange since the core OpenNebula daemon use the right information when deploying the VMs.

Regards.

network-without-vn_mad.png (79.2 KB) EOLE Team, 08/23/2016 09:22 AM

network-update-without-vn_mad.png (76.4 KB) EOLE Team, 08/23/2016 09:22 AM

Associated revisions

Revision 7a291125
Added by Carlos Martín over 4 years ago

Bug #4737: Add VN_MAD to vnet template when missing

Revision 020af4b4
Added by Carlos Martín over 4 years ago

Bug #4737: Add VN_MAD to vnet template when missing

(cherry picked from commit 7a291125f227c9380c76ac031810a546c3572ac9)

History

#1 Updated by Carlos Martín over 4 years ago

  • Category set to Core & System
  • Assignee set to Carlos Martín
  • Target version set to Release 5.2

#2 Updated by Carlos Martín over 4 years ago

  • Status changed from Pending to Closed
  • Resolution set to fixed

Thanks for reporting this, the fix will be included in the fsck tool

Also available in: Atom PDF